[whatwg] <video> resource selection algorithm and NETWORK_NO_SOURCE

On Mon, Jul 26, 2010 at 11:12 PM, Philip J?genstedt <philipj at opera.com>wrote:

> On Mon, 26 Jul 2010 14:53:50 +0200, Silvia Pfeiffer <
> silviapfeiffer1 at gmail.com> wrote:
>
>  On Mon, Jul 26, 2010 at 7:41 PM, Philip J?genstedt <philipj at opera.com
>> >wrote:
>>
>>  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.
>>>
>>>
>> Ok, I re-read the spec about <source> and you are correct: it's invalid to
>> create <source> elements without a @src attribute. It could, however,
>> still
>> be created without a URI, in which case the resulting state would indeed
>> be
>> a NETWORK_NO_SOURCE, since it fails to find a valid @currentSrc .
>>
>> I still think, though, that NETWORK_NO_SOURCE is a failure state, since it
>> is specified as
>> NETWORK_NO_SOURCE (numeric value 3):
>>    The element's resource selection algorithm is active, but it has failed
>> to find a resource to use.
>>
>
> Perhaps this wording should be changed. Given that this state is an
> integral part of skipping <source> elements where the type or media isn't
> supported, I really wouldn't call it a failure state, it's rather a waiting
> state.
>
>
>  I now wonder about the intention of play() (and also of pause()). As I
>> understood it, they are both meant to reload the media resource if
>> @currentSrc has changed, similar to what load() is supposed to do.
>>
>
> What the spec actually does right now is cause a change of the src
> attribute to trigger resource selection. There are no hooks for when you
> change the src attribute of a child source element, so that's why it looks a
> bit inconsistent.
>


Well, then this is the inconsistency. If I change @src on a <video> element
and then call play(), it will play. If I change @src on the <source>
elements of the <video> (and the <video> has no @src), the play() doesn't do
anything in Opera. This doesn't just look inconsistent, in actually *is*
inconsistent. (Maybe that's also what Maciej meant :). So, what is missing
is that a change on @src not just on <video> and <audio>, but also on
<source> needs to tirgger resource selection. This is another means of
getting around the problem.

On top of this, this still leaves us with inconsistent network states
between browsers, as you rightly noticed. A clarification of what
NETWORK_NO_SOURCE means is indeed needed.

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100726/1c8b8c38/attachment.htm>

Received on Monday, 26 July 2010 06:20:52 UTC