[whatwg] <video preload> implementation feedback

[Chris Pearce]

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.