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.
== 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.
I agree.
== 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?
}
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.
== <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).
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.
Regards,
Chris Pearce.
