W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] HTML5 video: frame accuracy / SMPTE

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 22 Jan 2011 09:25:57 +1100
Message-ID: <AANLkTimEmjShZxGqhkt9JFHdO5pb4WvEk8cTWxaDa+mP@mail.gmail.com>
On Sat, Jan 22, 2011 at 9:05 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Fri, Jan 21, 2011 at 4:57 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> * the default is best effort
>
> I fear that the "best effort" language is misleading. ?You can always
> do exact on a stream that you can seek to the beginning. So the "best"
> would be exact.

I am looking at this from the POV of the Web author to express "I
don't care how accurate you are seeking, just do a best effort" and it
is left to the browser to decide what that means. It may be exact, or
it may not. It just means that the author cannot rely on it being
exact.


> 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
the Web developer doesn't care. "Fast" requires the browser to use the
fastest seeking method. "Best effort" may be the same one that is the
fastest, or it may be one that is slightly less fast, but more
accurate, because the browser thinks it can afford to do the exact
seek without substantial overhead.

If we really want to enable another option next to "don't care", then
we should also introduce "FASTEST".


> 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.


>> * 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.
Received on Friday, 21 January 2011 14:25:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC