[whatwg] <video> resource selection algorithm and NETWORK_NO_SOURCE

I actually don't think there's anything wrong about the spec as it is.

NETWORK_NO_SOURCE is not a state of failure, it is a waiting state. Here's  
what happens as the parser inserts elements into the DOM:

<video controls width="400px">
<!-- video has been inserted but resource selection hasn't run -->
   <source type="video/mp4">
<!-- resource selection is started, ends on step 21 with NETWORK_NO_SOURCE  
and pointer pointing to just after the only source element -->
   <source type="video/webm">
<!-- resource selection continues at step 22, going another loop and  
ending at step 21, but with pointer pointer to after the second source  
element -->
   <source type="video/ogg">
<-- same as above, but pointing to after the third source element -->
</video>

If nothing is done, the resource selection algorithm will wait forever at  
step 21. To get out of that state you have to either call load() to  
restart resource selection, or append another source element.

If we should let networkState be NETWORK_EMPTY after inserting the dummy  
<source> elements, then resource selection would be run from the beginning  
each time, which means that during parsing, the first <source> element  
will be considered 3 times, the second 2 times and the last 1 time. In  
your example this doesn't matter, but if the reason a <source> failed was  
because of network errors, unsupported Content-Type or an unsupported file  
format, then that will also happen too many times, adding useless network  
traffic (unless e.g. 404 results are cached).

So, I think the algorithm should stay as it is and that the other browsers  
should change their implementations. In your original example you used  
<source> elements with no src attribute. This is invalid, and I think the  
proper solution would be to create each source element, set the src  
attribute and append it to the video element.

Philip

On Sat, 24 Jul 2010 05:51:12 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> There is definitely a spec bug, because different locations of the spec  
> say
> diverging things. While the first step in the resource selection  
> algorithm
> states to go into NETWORK_NO_SOURCE state, the description of
> NETWORK_NO_SOURCE in the spec actually implies a state of failure. Since  
> the
> first step in the resource selection algorithm really is a state where we
> know nothing about the resource yet, it matches more with the  
> description of
> NETWORK_EMPTY:
>
> NETWORK_EMPTY (numeric value 0)
>     The element has not yet been initialized. All attributes are in their
> initial states.
>
> NETWORK_NO_SOURCE (numeric value 3)
>     The element's resource selection algorithm is active, but it has  
> failed
> to find a resource to use.
>
> In any case, it would be nice to get the spec corrected either way and  
> the
> implementations aligned. :)
>
> Cheers,
> Silvia.
>
>
> On Sat, Jul 24, 2010 at 12:16 AM, Philip J?genstedt  
> <philipj at opera.com>wrote:
>
>> Silvia made we aware of discrepancy in how browsers implement the  
>> resource
>> selection algorithm, see forwarded message. It's my assessment that  
>> Opera is
>> the only browser following the spec. I've filed this bug with Mozilla:
>>
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=581355
>>
>> I've also reported bugs in Chrome and Safari, but can't see where they
>> ended up.
>>
>> The reason I'm writing this email is that apparently everyone but myself
>> has a different interpretation of the spec, so perhaps this is  
>> something we
>> need to discuss. Does any other browser ever set the state  
>> NETWORK_NO_SOURCE
>> at all? I speculated that perhaps other browsers aren't very strict  
>> about
>> which parts of the algorithm are run synchronously and not, but even
>> checking the networkState after a setTimeout it still isn't
>> NETWORK_NO_SOURCE.
>>
>> Test case: http://people.opera.com/philipj/2010/07/23/networkState.html
>>
>> Please fix implementation or spec :)

-- 
Philip J?genstedt
Core Developer
Opera Software

Received on Monday, 26 July 2010 02:41:48 UTC