On Nov 1, 2011, at 3:10 PM, Victoria Kirst wrote: > - *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 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. > 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. > 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? 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"? > - *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. Again, this is a clear example of a situation where the browser could easily and safely emit a canplaythrough event. > - *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. 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. > 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(). 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. -Jer
