- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 17 Aug 2011 17:44:55 +0200
Greetings, Opera's implementation [1] of <video preload> and the testsuite [2][3] has been available for about a month now. While implementing this, we found and reported a number of issues. [4-10] In general, it is my opinion that <video preload> is under-defined, giving implementors more freedom than is necessary or useful. We have done our best to implement and test something that we feel makes sense. I'm sure that other browsers will do things slightly different and that standardization will be necessary for web compat down the line. I'd very much like to see feedback from other implementors. Are you happy with treating autoplay and preload as "just hints" as in [4] or do you think that we should specify them in greater detail? (This does not preclude having user preferences to override the standardized defaults.) Specific issues that don't have open bugs: == Internal preload state == We maintain an internal preload state that is not always in sync with the content attribute. This internal state is what actually determines which buffering mode is used. For example, if the content attribute is "none" but the user starts playing, then the internal state is promoted to "auto". Since the existence and behavior of this internal state is script-detectable, I think it would make sense to specify it. Any of the following promotes the internal state to "auto": 1. The presence of autoplay forces it to "auto" 2. Calling play() by script or native controls 3. Setting currentTime by script or native controls All of these are unconditional and can only be undone by resetting the internal preload state, see below. == Dynamically changing preload == It makes no sense for a script to change preload="auto" to preload="none". Going from preload="auto" to preload="metadata" isn't nonsensical, but supporting it would allow authors to toggle it continuously to work around buggy buffering behavior. I'd much rather that buffering problems be fixed in the browser, so I don't want to support this. Consequently, we only allow the internal preload states to increase, not decrease. I understand that Mozilla has done the same. Unless there are strong reasons not do, I think this should be spec'd. == Resetting internal preload state == Due to the above, it's necessary to reset the internal preload state at some point. Otherwise, a script like this wouldn't work: function setSource(url) { var v = document.querySelector('video'); v.src = url; v.preload = "none"; v.onplay = function() { v.preload = "autoplay"; }; } If a previous resource was playing and preload was set to "autoplay" by script, then we still want preload="none" to apply to the new resource. To solve this, we are resetting the internal preload state as part of the resource selection algorithm, right before step 5 to fire the loadstart event. There are various other places one could do this, but we think it is important to do it in the async section so that the order of setting .src and .preload does not matter. == <video preload="none"> == It's not possible to specify exactly how much preload="metadata" and preload="auto" buffers and when, but this is possible for preload="none". This is what we do: After step 1 of the source selection algorithm, if preload=="none", set networkState to IDLE, fire a suspend event and set the delaying-the-load-event flag to false. [1] http://my.opera.com/desktopteam/blog/2011/07/14/javascript-on-a-diet [2] http://w3c-test.org/html/tests/submission/Opera/preload/overview.html [3] http://w3c-test.org/html/tests/submission/Opera/preload/runner.php [4] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11602 [5] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11981 [6] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12175 [7] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267 [8] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12595 [9] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12596 [10] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12608 -- Philip J?genstedt Core Developer Opera Software
Received on Wednesday, 17 August 2011 08:44:55 UTC