W3C home > Mailing lists > Public > public-html@w3.org > February 2011

Re: <video> readyState oddities

From: Philip Jägenstedt <philipj@opera.com>
Date: Sat, 19 Feb 2011 11:14:38 +0100
To: public-html@w3.org
Message-ID: <op.vq5aqovgsr6mfa@nog>
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 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.

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.

Philip Jägenstedt
Core Developer
Opera Software
Received on Saturday, 19 February 2011 10:15:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:09 UTC