W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2011

[whatwg] <video preload> implementation feedback

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 17 Aug 2011 17:44:55 +0200
Message-ID: <op.v0c7c51usr6mfa@kirk>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC