Re: <video> readyState oddities

On Fri, 25 Feb 2011 02:50:07 +0100, Ian Hickson <ian@hixie.ch> wrote:

> On Sat, 19 Feb 2011, Philip Jägenstedt wrote:
>> On Fri, 18 Feb 2011 21:42:46 +0100, Ian Hickson <ian@hixie.ch> wrote:
>> > On Thu, 17 Feb 2011, Chris Pearce wrote:
>> > > >
>> > > > 2. When you run out of buffered data when playing normally, should
>> > > > readyState revert to HAVE_CURRENT_DATA or HAVE_METADATA? The
>> > > > answer depends on what currentTime is at that point, it seems.
>> > >
>> > > Firefox won't drop below HAVE_CURRENT_DATA once it's passed it, the
>> > > logic being that we're still able to display the frame which we're
>> > > currently displaying. So we drop back to HAVE_CURRENT_DATA in this
>> > > case.
>> >
>> > The spec currently states that CURRENT_DATA is for when "Data for the
>> > immediate current playback position is available", so per spec this
>> > would be wrong.
>> >
>> > I think it is relatively important to have the spec's behaviour;
>> > without it, it's impossible for the author to know if you're
>> > displaying what he wants you to display or if you're still trying to
>> > decode it.
>>
>> The spec doesn't quite define how to interpret "current playback
>> position" when you run out of data, or am I missing it?
>
> I don't understand. What is ambiguous? The spec defines everything that
> happens to the current playback position, no?

Let's see then...

"When a media element is potentially playing and its Document is a fully  
active Document, its current playback position must increase monotonically  
at playbackRate units of media time per unit time of wall clock time."

During normal playback, whether or not currentTime increases depends on  
"potentially playing":

"A media element is said to be potentially playing when its paused  
attribute is false, the readyState attribute is either HAVE_FUTURE_DATA or  
HAVE_ENOUGH_DATA, the element has not ended playback, playback has not  
stopped due to errors, and the element has not paused for user  
interaction."

In other words, when readyState is HAVE_METADATA or HAVE_CURRENT_DATA,  
currentTime doesn't change, but I can't see that it's clearly defined if  
readyState should fall back to HAVE_METADATA or HAVE_CURRENT_DATA when  
playback has ended or you just ran out of buffer.

My reading would be that it depends on if the end of buffered TimeRanges  
are inclusive or not. Example: if buffered.end(0) == 1 and currentTime ==  
1, is "Data for the immediate current playback position is available"? Is  
readyState HAVE_METADATA or HAVE_CURRENT_DATA?

>> I think it would make sense to behave the same way as at the end of the
>> resource, and that HAVE_CURRENT_DATA actually makes sense.
>
> Not sure what you mean.

Running out of data because the network is slow or because the end of the  
resource has been reached is really very similar on the decoding side of  
things, so I think the state should be the same for consistency, be that  
HAVE_METADATA or HAVE_CURRENT_DATA.

In the best of worlds we wouldn't have these two barely distinguishable  
states, but clearly this is not the best of worlds.

>> The only case where HAVE_METADATA seems right is when nothing has been
>> decoded yet, i.e. when just starting to load the resource and when
>> seeking to an unbuffered time offset.
>
> HAVE_METADATA is the state for when you don't have anything except
> metadata for the current playback position, for example because playback
> is stalled because the UA is still downloading the data for this  
> position.

See above.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Friday, 25 February 2011 10:20:45 UTC