On Thu, 18 Aug 2011 04:50:17 +0200, Chris Pearce <cpea...@mozilla.com>
wrote:
I implemented preload support in Firefox.
On 18/08/2011 3:44 a.m., Philip Jägenstedt wrote:
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?
I think autoplay should not be treated as a hint, else it's can't be
relied upon to work, and thus would be completely useless.
Preload is a less critical; if it's not supported users will just end up
loading more data, which isn't too bad. Clients that care more about
bandwidth will probably be more likely to support it.
I think that too much variation in how preload is implemented is also
likely to give compat problems. In
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=12596#c7> I have an example
of what might break when pages inevitably assume that preload="none"
causes the loadedmetadata event to not be fired.
== 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"; };
Did you mean |v.preload = "auto";| here instead? or |v.autoplay =
true";|? It seems in this case the onplay handler would only happen if
the user pressed play on the controls or from script, so the preload
action be promoted to auto anyway since the resource is playing. I guess
that's what you're getting at with your point about preload internal
state promotion?
Oops, it should be v.preload = "auto". Indeed this example is more
complicated than necessary. Promotion of the internal state due to user
interaction also needs to be reset in the resource selection algorithm, so
any time that a HTMLMediaElement is reused this is a problem.
}
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.
Currently we update the internal preload action whenever the value of
the preload state changes, and we check it's not preload=none before
kicking off a new resource load (resource fetch algorithm step 2) and we
check it again when we reach loadedmetadata and suspend the load if it's
preload=metadata.
I think the preload=metadata case is implied by the spec, but having it
explicitly stated wouldn't hurt.
It sounds like we're applying preload=none at exactly the same point,
that's good!
If you only allow the internal state to increase, don't you need to reset
it at some point as well? Or is it impossible in your implementation to
use preload="auto" on one load and preload="metadata" on the next due to
this?
== <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.
This is actually specified now in step 2 of the resource fetch algorithm
(this must have been added after we implemented @preload).
Right, this is the partially accepted resolution of
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12596
Doing this at step 1 of the resource selection algorithm means that if
you're loading from child <source> elements, and none of them have a
supported type, then you won't report the error until something calls
play() or load() explicitly.
Oops, I meant "resource fetch algorithm" and what I have implemented is
exactly what the spec says, except that it's unconditional and the
"implementation-defined event" is playing or seeking.
Thanks for your feedback!
--
Philip Jägenstedt
Core Developer
Opera Software
