On Fri, Jan 21, 2011 at 7:27 PM, Silvia Pfeiffer
<silviapfeiff...@gmail.com> wrote:
> On Sat, Jan 22, 2011 at 9:48 AM, Gregory Maxwell <gmaxw...@gmail.com> wrote:
>> On Fri, Jan 21, 2011 at 5:25 PM, Silvia Pfeiffer
>> <silviapfeiff...@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.
This is certainly not the implication it carries for me, but I don't
see any point in arguing it further.
>>> 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.
That is not always true. If you're at frame 5 the _fastest_ possible
way to seek to frame 6 is to simply decode frame 6 (and probably also
the case for quite a few subsequent frames assuming that the decode is
fast and the data is in cache, while the nearest keyframes are not in
cache). If you're at frame 800 then the fastest way to seek to frame
6 may be to start from frame three.
It's a toy example, I know. But I think it makes the point that
consistency has to be explicitly decided for any modes which are not
implementation dependent. It might be reasonable enough to say "if
you need guaranteed consistency, use the exact mode".
> 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
I have no complaints about these. I still think we've left the
inaccurate but right direction case uncovered. And perhaps its
over-design, but its also functionality that exists in current media
players. E.g. mplayer will do correct-direction inaccurate seeks,
though this may just be an artifact of the tools not having decent
exact seeking logic at all.
