[whatwg] Proposal: Remove canplaythrough event from audio/video tag

[Victoria Kirst]

Hi Jer!

Your email made me realize that instead of proposing the event's removal,
what I really should have said was, "I am confused about this event. Can
someone help me understand what I am missing?" Whoops. I retract my
proposal; it was extreme because it was largely based on ignorance, it
seems. Sorry about that!

A few comments inline...

The purpose of the canplaythrough event (and of the HAVE_ENOUGH_DATA ready
> state) are to signal to the page author that playback is likely to keep up
> without stalling.  This seems to me to have a fairly obvious benefits.
>
> Here's a hypothetical scenario:
>
> Assume a 100% accurate implementation of canplaythrough (in that the UA
> can predict with 100% accuracy at what time in the future will the final
> byte of media data will be downloaded.)  Assume magic or time travel if
> necessary.
>
> In this scenario, a <media> element with with a canplaythrough listener
> will always begin playing at the earliest possible time and will never
> stall during normal playback. This is a clear benefit.
>

Yeah, and as Eric Carlson pointed out to me offline, this is very useful
for scripting autoplay. Makes sense.

> The question I keep running into is *how inaccurate can the browser be
> > until the event is no longer useful?*
>
> This seems to be a Quality of Service issue.  Different UAs will have
> different implementations of canplaythough at varying degrees of accuracy.
>  Some UAs will favor a lower possibility of stalling over an earlier start
> time.  Others may cut closer to the margin-of-error and favor earlier start
> times.


This was something I was more concerned about when I was aiming to
calculate a precise download speed instead of thinking in terms of having
buffered "enough" to for smooth playback. (See comments below.)


> I think this is a very bad example for your case.  If the browser has
> decided to postpone further downloading once it has "reached a comfortable
> buffer", shouldn't it have already fired a "canplaythrough" event and set
> its readyState to HAVE_ENOUGH_DATA?  Isn't that the very definition of
> reaching "a comfortable buffer"?
>

Ah -- actually, this made me realize that I was misinterpreting the spec a
bit! I wasn't thinking about canplaythrough as something that could be a
reflection of buffer state, but instead was focused on making it reflection
of purely download speed (when buffering, of course, is an indirect
indication of download speed). This makes sense! Thanks for pointing it out.


> Again, this is a clear example of a situation where the browser could
> easily and safely emit a canplaythrough event.
>

Sure, this makes more sense now.


> The spec makes it clear that HAVE_ENOUGH_DATA is an estimate.  And this
> situation makes a more compelling argument to /add/ a
> 'cannolongerplaythrough' event for use when the UA detects a suddenly
> bandwidth-limited connection.  For example, with such an event, a page
> author may decide to switch to a lower-bitrate version of the media file.
>

Yes, I agree that the spec makes it clear that HAVE_ENOUGH_DATA is an
estimate. Still, somehow, until your email, I was hung up on the idea of
calculating an accurate download rate... I guess it's because under the
description of HAVE_ENOUGH_DATA, the spec says, "the user agent estimates
that data is being *fetched at a rate* where... [blah blah blah]." I'm
trying to think if I would prefer some other wording, but it seems clear in
retrospect. :)

I also didn't realize the video ready state is expected to be moving
between HAVE_CURRENT_DATA, HAVE_FUTURE_DATA, and HAVE_ENOUGH_DATA in
response to the changing network condition and also possibly as the
browser's adapts its estimation techniques. Again, I'm not sure if/how I
would propose rewording the spec. A "cannolongerplaythrough" event (or
similar) seems like something that would be useful, but I should probably
think about this more.


> No, a page author cannot.  For example: if progress events stall, a page
> author cannot tell that the UA has decided to "postpone loading" after
> reaching a "comfortable buffer".  The point of the event and the readyState
> is that the UA has knowledge of media loading and decoding that the page
> author does not.  The UA is simply in a much better position to estimate
> whether a media can play though than is the page author.
>

Sounds fair.

The motivation and implementation for the event are much clearer now. I
will come back with more questions as I approach them, with maybe a less
scary subject-line! :) I will finish up my CL for this event now!

Thanks again for the clarification!
Victoria