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

Hello all!

I'm an engineer on the Chrome team, and I have been working on implementing
the canplaythrough event for Chrome video. As I've been working out the
best way to implement it, I've realized I am at a loss to explain how the
canplaythrough<http://www.w3.org/TR/html5/video.html#event-mediacontroller-canplaythrough>
event
is valuable for the user. I'd like to start a discussion about the
possibility of removing the event from the spec entirely.

It'd be helpful to know answers to the following questions:

   - *What is the history of the canplaythrough event?* What was the
   reasoning behind it when it was introduced into the spec?
   - *What are some real examples of how canplaythrough is useful for a web
   developer?* Even if it were 100% accurate, what is the benefit of the
   event? Given that it's* not* 100% accurate and that the accuracy is
   largely up to the discretion of the web browser, what is the benefit?

The spec <http://www.w3.org/TR/html5/video.html#event-media-canplaythrough> is
(perhaps purposely) pretty vague on the specifics of implementing the
event. From the browser implementors' perspective, it's hard to decide what
the browser should do in the gray areas, especially when lacking answers to
the questions above.

The question I keep running into is *how inaccurate can the browser be
until the event is no longer useful?* The only way to be 100% accurate when
firing the event is to wait until after the entire video is downloaded,
which seems to defeat the purpose -- though admittedly, I'm not sure what
the purpose of the event really is.

There are many ways to approximate download speed, but it quickly becomes
complicated to maintain accuracy:

   - *Throttled downloads:* So as not to unnecessarily download too much
   data, browsers may postpone its download of the media file after it has
   reached a comfortable buffer. In this case, how should the download speed
   be approximated? Should the browser only measure during active downloading,
   or should the deferring somehow be factored in?
   - *Amount of data for accurate bandwidth estimation:* When can the
   browser feel comfortable with its estimation of download speed? It seems
   like the browser's calculation would be pretty noisy unless it has at least
   a few (~5) seconds of data. But the browser won't always have that luxury:
   for example, if the browser is throttling download under high-speed
   internet connection, the browser could mostly be downloading in very short
   bursts, and each burst on its own may not be "long enough" to get a
   comfortable estimate.
   - *Inherent inaccuracy*: As I previously stated, the only way to be 100%
   accurate in firing this event is to wait until the last byte has been
   downloaded before firing the event. Firing the event at any time before
   then will *always* be a guess, not a guarantee. Someone can unplug their
   connection, or move to a stronger/weaker wifi connection, which will
   immediately invalidate any estimation from data collected before.

Given the uncertainty of the event's usefulness, and the trickiness
involved in implementing it accurately, I propose removing canplaythrough
from the spec if there is not an abundance of compelling cases in support
of the event. A web developer can implement his or her own version of
canplaythrough by monitoring progress events and buffered().

Victoria

Received on Tuesday, 1 November 2011 15:10:44 UTC