<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 8, 2009, at 5:32 AM, Philip Jägenstedt wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Thu, 08 Oct 2009 12:10:01 +0200, Robert O'Callahan <<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>> wrote:<br><font class="Apple-style-span" color="#006312"><br></font></div></blockquote><blockquote type="cite"><div><blockquote type="cite">Another issue is that it's not completely clear to me what is meant by<br></blockquote><blockquote type="cite">"While the user agent might still need network access to obtain parts of the<br></blockquote><blockquote type="cite">media resource<<a href="http://www.whatwg.org/specs/web-apps/current-work/#media-resource">http://www.whatwg.org/specs/web-apps/current-work/#media-resource</a>>..."<br></blockquote><blockquote type="cite">What if there is data in the resource that we don't need in order to<br></blockquote><blockquote type="cite">play through normally, but which might be needed in some special situations<br></blockquote><blockquote type="cite">(e.g., enabling subtitles, or seeking using an index), and we optimize to<br></blockquote><blockquote type="cite">not load that data unless/until we need it? In that case would we never<br></blockquote><blockquote type="cite">reach NETWORK_LOADED?<br></blockquote><br>As I understand it, NETWORK_LOADED means that all bytes of the resource have been loaded, regardless of whether they will be used or not. Are there any formats that would actually allow not downloading parts of the resource in a meaningful way? </div></blockquote><div><br></div><div><div> Yes. A disabled track in an MPEG-4 or QuickTime file is not rendered so the data is not used when presenting the movie. Media data for an enabled but invisible video track (eg. size 0x0, or not within the visible region) or an enabled but muted audio track isn't technically needed for the presentation either.</div></div><div><br></div><br><blockquote type="cite"><div>Subtitles and indexes are too small to bother, and multiplexed audio/video tracks can hardly be skipped without zillions of HTTP Range requests. It seems to me that kind of thing would have to be done either with a server side media fragment request (using the 'track' dimension) or with an external audio/video track somehow synced to the master track (much like external subtitles).<br><br></div></blockquote><div> I don't agree that this is necessarily best done on a server. Some file formats include tables with the location of every sample, so a media engine that uses range requests anyway can easily read just the data needed. It might be wise for such an engine to optimize the size of chunks read from the server, but that is an implementation detail.</div><div><br></div><div> Also remember that "multiplexed" is a relative term, different chunking/interleaving schemes make sense for different media types and use cases so not all multiplexed files interleave data in small chunks.</div><div><br></div><br><blockquote type="cite"><div><blockquote type="cite">In general NETWORK_LOADED and the "load" event seem rather useless and<br></blockquote><blockquote type="cite">dangerous IMHO. If you're playing a resource that doesn't fit in your cache<br></blockquote><blockquote type="cite">then you'll certainly never reach NETWORK_LOADED, and since authors can't<br></blockquote><blockquote type="cite">know the cache size they can never rely on "load" firing. And if you allow<br></blockquote><blockquote type="cite">the cache discarding behavior I described above, authors can't rely on data<br></blockquote><blockquote type="cite">actually being present locally even after "load" has fired. </blockquote></div></blockquote><div><br></div> If data can be evicted from the cache you can never reach NETWORK_LOADED because "Network connectivity could be lost without affecting the media playback".</div><div><br></div><div><br><blockquote type="cite"><div><blockquote type="cite">I suspect many<br></blockquote><blockquote type="cite">authors will make invalid assumptions about "load" being sure to fire and<br></blockquote><blockquote type="cite">about what "load" means if it does fire. Does anyone have any use cases that<br></blockquote><blockquote type="cite">"load" actually solves?<br></blockquote><br></div></blockquote><div><div> I also agree that the 'load' event and the NETWORK_LOADED state are not terribly useful and will likely cause a great deal of confusion for developers. We have have seen a number of cases where experienced web developers have used the 'load' event when they should have used the 'canplaythough', and I fear that this will be a common mistake.</div><div><br></div></div><br><blockquote type="cite"><div>I agree, sites that depend on the load event sites will likely break randomly for file sizes that usually barely fit into the cache of the browser they were tested with. If browsers are conservative with bandwidth and only send the load event when it's true, I think we will have less of a problem however. </div></blockquote><div><blockquote type="cite"><br></blockquote></div><div> I don't agree that it will be any less of a problem if browsers are conservative, users will still not *ever* be able to depend on the 'load' event firing (except perhaps for local files).</div><div><br></div><br><blockquote type="cite"><div>Note that the load event isn't strictly needed, waiting for a progress event with loaded==total would achieve the same thing.<br><br></div></blockquote><div> Actually, a progress event with loaded==total tells you even less than the 'load' event because it doesn't guarantee that the data won't be evicted from the cache.</div><div><br></div><div><br></div><div><blockquote type="cite"><div> Aesthetically, however, I think it would be strange to not have the load event.</div></blockquote><br></div><div> I am not worried about the aesthetics of not having the event. I am somewhat concerned about existing content that uses it (including many of the WebKit layout tests :-( ), but I think we will be better off in the long run if we get rid of the event and network state now.</div><div><br></div><div>eric</div><div><br></div></div></body></html>