[whatwg] <video preload> implementation feedback
Philip Jägenstedt
philipj at opera.com
Wed Aug 17 08:44:55 PDT 2011
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
More information about the whatwg
mailing list