[whatwg] <video preload> implementation feedback

On Thu, 18 Aug 2011 04:50:17 +0200, Chris Pearce <cpearce at 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

Received on Thursday, 18 August 2011 05:01:41 UTC