- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sat, 22 Jan 2011 11:27:33 +1100
On Sat, Jan 22, 2011 at 9:48 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Fri, Jan 21, 2011 at 5:25 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>>> The language I'd prefer is "fast". ?Fast may be exact, or it might
>>> just be to the nearest keyframe, or something in between. It might
>>> just start you over at the beginning of the stream.
>>
>> That is putting a restriction on how the browser has to seek -
>> something I'd rather leave to the browser in the general case where
>
> No more than 'best' is, I suppose. I think you missed the argument I'm
> making: I'm saying that it's perfectly reasonable to assume that "Best
> effort" means "exact" in any seekable stream, because exact is best
> and best is always possible. ?This is the same kind of reasoning
> sequence that allows you to conclude that "fast" requires the browser
> to use the fastest.
Except that "best effort" has a tradition in meaning "probably not the
best possible way and inexact", while "fast" would imply to people
that there is no faster way of doing it.
>>> One question about inexact seeking is what should the client do when
>>> the current playtime is closer to the requested time than what the
>>> inexact seek would provide?
>>
>> In the case of "fastest", the browser must then not do a seek. In the
>> case of "don't care", it's up to the browser if it does the seek or
>> not.
>
> That was my thinking, but I find the consistency point raised by Glenn
> to be concerning.
If "fast" always means "the fastest possible way", then it will be
consistent. It may mean that we need to specify it a bit more to be
consistent, but it would mean that. While "default" would be a best
effort and therefore cannot be expected to be consistent.
>>>> * KEYFRAME is keyframe-accurate seeking, so to the previous keyframe
>>>
>>> What does this mean when a seekable stream doesn't have interior
>>> keyframes? Should the client always seek to the beginning? Why is this
>>> valuable over a "fast" option?
>>
>> Where no keyframes are available, this seek option simply doesn't do
>> anything, since obviously there are not keyframes. The point is that
>> where this concept exists and people want to take advantage of it,
>> this seek should be possible.
>
> I really feel that "keyframe" is far deeper into the codec internals
> than should be or currently is provided by rest of the video API.
> I've frequently seen content authors and application developers make
> incorrect assumptions about key-frames: That they always indicate
> scene changes, that they always occur at an exact interval, that two
> differently encoded files will have the keyframes in the same places.
> Etc. ?That these things are sometimes true feeds the mistaken
> impressions. ?The frametypes inside a codec are really deep internals
> that we ought not encourage people to mess with directly.
I could live with a seeking method without keyframe seeking. But frame
accurate seeking needs to be possible. So we end up with:
* default ("best effort")
* TIME (or ACCURATE)
* FRAME
* FASTEST
> It seems surprising to me that we'd want to expose something so deeply
> internal while the API fails to expose things like chapters and other
> metadata which can actually be used to reliably map times to
> meaningful high level information about the video.
>
Chapters have an API:
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-kind-chapters
.
However, chapters don't have a seeking API - this is indeed something
to add, too. Could it fit within the seek() function? e.g.
seek(chaptername) instead of seek(time)?
Silvia.
Received on Friday, 21 January 2011 16:27:33 UTC