W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] <video> resource selection algorithm and NETWORK_NO_SOURCE

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 24 Jul 2010 22:31:32 -0700
Message-ID: <DA46054F-0CF2-4277-9384-A54C5052F7D5@apple.com>

On Jul 23, 2010, at 7:16 AM, Philip J?genstedt 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 :)

1) Which behavior is more useful?
2) Sylvia's original issue was with play() - should we ensure that any time you call play(), it will cause the media resource to start playing once loaded? That seems like the real spec bug.

Regards,
Maciej


> -- 
> Philip J?genstedt
> Core Developer
> Opera Software
> 
> ------- Forwarded message -------
> From: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>
> To: "Philip J?genstedt" <philipj at opera.com>
> Cc:
> Subject: Re: bug in Opera video
> Date: Thu, 22 Jul 2010 12:51:15 +0200
> 
> Hi Philip,
> 
> On Thu, Jul 22, 2010 at 8:02 PM, Philip J?genstedt <philipj at opera.com>
> wrote:
>> On Thu, 22 Jul 2010 01:23:09 +0200, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com> wrote:
>> 
>>> Hi Philip,
>>> 
>>> I've just made an experiment with the play() function in Opera and it
>>> seems that Opera doesn't support play() if currentSrc has not been
>>> determined yet (i.e. if the media element doesn't have a loaded
>>> resource). The spec says to deal with this situation and so do all
>>> other browsers, bar Opera. Here is a test:
>>> 
>>> <!DOCTYPE html>
>>> <html lang="en">
>>> <body>
>>>   <video controls width="400px">
>>>     <source type="video/mp4">
>>>     <source type="video/webm">
>>>     <source type="video/ogg">
>>>   </video>
>>>   <p>currentSrc on start: <span id="currentSrc_first"></span>.</p>
>>>   <p>currentSrc after loadedmetadata: <span
>>> id="currentSrc_loadedmetadata"></span>.</p>
>>>   <script type="text/javascript">
>>>     video = document.getElementsByTagName("video")[0];
>>>     source = document.getElementsByTagName("source");
>>> 
>>>     span1 = document.getElementById("currentSrc_first");
>>>     span1.innerHTML = video.currentSrc;
>>>     source[0].src = "HelloWorld.mp4";
>>>     source[1].src = "HelloWorld.webm";
>>>     source[2].src = "HelloWorld.ogv";
>>>     video.play();
>>> 
>>>     span2 = document.getElementById("currentSrc_loadedmetadata");
>>>     function span2Update(evt) {
>>>         span2.innerHTML = video.currentSrc;
>>>     }
>>>     video.addEventListener("loadedmetadata", span2Update, false);
>>>   </script>
>>> </body>
>>> </html>
>>> 
>>> The video.play() function should execute the resource selection and
>>> fetching, but it doesn't. Not sure if this is deliberate and you want
>>> a discussion on the whatwg about it, or just a bug.
>>> 
>>> Cheers,
>>> Silvia.
>>> 
>> 
>> The spec says "If the media element's networkState attribute has the value
>> NETWORK_EMPTY, invoke the media element's resource selection algorithm."
>> 
>> I added alert(video.networkState) just before video.play. In Opera it is 3
>> (NETWORK_NO_SOURCE) while in Chrome it is 0 (NETWORK_EMPTY).
> 
> Ah, yes, this is actually another thing I wanted to alert you to. All
> other browsers set the @networkState to NETWORK_EMPTY at the start of
> loading a new media resource (Firefox, Safari and Chrome). I was going
> to discuss this with you, since Opera interprets the spec different
> here - which is understandable, since the first step in the resource
> selection algorithm says to:
> 1. Set the networkState to NETWORK_NO_SOURCE.
> 
> OTOH however, the description for the NETWORK_NO_SOURCE state is as
> follows:
> NETWORK_EMPTY (numeric value 0)
>     The element has not yet been initialized. All attributes are in
> their initial states.
> and for NETWORK_NO_SOURCE is:
> NETWORK_NO_SOURCE (numeric value 3)
>     The element's resource selection algorithm is active, but it has
> failed to find a resource to use.
> 
> Thus, I believe this may be a spec bug and really the first step in
> the resource selection algorithm should say
> 1. Set the networkState to NETWORK_EMPTY.
> which is more consistent with the implementations of the other
> browsers and also consistent with the meaning of NETWORK_EMPTY and
> NETWORK_NO_SOURCE.
> 
> 
>> We are
>> following the spec here, as the resource selection algorithm should be run
>> the first time when the video element is inserted into the DOM by the
>> parser, then again after each source element is inserted. For this markup,
>> it will stay as NETWORK_NO_SOURCE in all cases, which is basically a waiting
>> state.
>> 
>> There are a few ways we could go about solving this:
>> 
>> 1. Make modifying the src attribute of source elements that are children to
>> a video element that has state EMPTY or NO_SOURCE run the resource selection
>> algorithm. I don't like this idea myself, it's unnecessarily complicated.
>> 
>> 2. Let the other browsers follow the spec and add a call to video.load()
>> before video.play().
>> 
>> Please do bring this up with the WHATWG. If you like you can forward this
>> mail verbatim. To anyone testing this, note that HelloWorld.mp4 has to
>> actually exist (or changed to something that does) for the above test to
>> work.
> 
> Actually, in cases where it doesn't exist, all other browsers can deal
> with it, but Opera hangs. I have actually posted that to Opera bug
> reports if you want to follow up on this, too.
> 
> I'm leaving it to you to bring it up at WHATWG, since it seems that
> the Opera implementation is the odd one out. :-)
> 
> Cheers,
> Silvia.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100724/1887dc58/attachment.htm>
Received on Saturday, 24 July 2010 22:31:32 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC