Re: <video> readyState oddities

On Fri, 25 Feb 2011, Philip Jägenstedt wrote:
> 
> Because of the definition of "potentially playing", currentTime cannot 
> increase once readyState has falled back to HAVE_CURRENT_DATA, so I 
> assume you meant HAVE_FUTURE_DATA in the above?

Oops. The definition of "potentially playing" is wrong. Fixed.

The spec was indeed self-contradictory before in numerous ways because of 
this mistake. My bad. (For example, 'waiting' would never fire per the 
previous definition.)


> If buffered is [0,10] then one would reasonably expect currentTime to 
> increase monotonically until it is exactly 10. Where else would it stop, 
> 10.0000001?

It would stop at the start time of the next frame of video. Assuming for 
the sake of argument a video with ten frames per second, the 100th frame 
would start at 9.9s and end at 10.0s minus epsilon. The 101th frame would 
be from 10.0s to 10.1s, and so it would stop at 10.0s.

Actually I guess I'm arguing that it's exclusive, not inclusive, because 
t-epsilon < t but will round to t in the API. So it's inclusive in 
principle but in practice it's exclusive...


> > It seems extremely different in one key respect: when you have ended, 
> > the frame you _want_ to be rendering is the last one, but when you 
> > have run out of data, the frame you _want_ to be rendering is the next 
> > one.
> 
> Surely the difference between HAVE_METADATA and HAVE_CURRENT_DATA should 
> correspond to whether or not currentTime is in the buffered ranges, not 
> be special-cased for currentTime==duration?

I don't understand the difference.


> Think of a video resource sent over HTTP without Content-Length or 
> support for range requests, such that one doesn't know when it will end 
> until it does. Reaching the end and running out of data because of a 
> slow network would be indistinguishable until after the fact.

My assumption when writing the spec would be that the user agent would 
find out the actual duration of the previously-assumed-infinite stream 
before or as it rendered the last frame, so that durationchange would fire 
at the latest just before currentTime was advanced to past the end of the 
last frame, and so this problem would not occur.

The spec doesn't currently seem to handle the situation of seeking to a 
point beyond the end of a presumed-infinite stream, whether by advancing 
monotonically to that point or arbitrarily seeking to that point. I should 
probably fix that. Filed bug:

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=12191


> The last byte would be received before one knows that the server has 
> closed the connection, after all.

Sure, but the end of the connection would presumably be received before 
the client tried to render the frame beyond the end of the connection, 
unless the server stalled at that point. If the server stalled at that 
point, then you run into the problem filed above, which the spec really 
needs to handle. I guess the way to handle it is to snap currentTime to 
the end of the stream once the new duration is known, and fire timeupdate 
and ended events.


> It would be very strange if readyState had to change when the server 
> says "EOS", even though nothing has changed from a decoding perspective. 
> It's *possible* to implement, but it seems strange and inconsistent.

Well assuming the stream didn't stall, readyState wouldn't change (it 
would stay HAVE_CURRENT_FRAME). If the stream _did_ stall, then it would 
make sense to change, since the browser would go from thinking it was 
missing data (HAVE_METADATA, currentTime > T) to thinking it was at the 
end of the stream (HAVE_CURRENT_DATA, currentTime = T).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'