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

[whatwg] <video> loading algorithms

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 9 Dec 2010 11:12:06 +1100
Message-ID: <AANLkTim_1srvZgWUyvYuY37nXShvzorVsTFDkugH5L6S@mail.gmail.com>
>> On Mon, 26 Jul 2010, Silvia Pfeiffer wrote:
>> > >
>> > > 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.
>> >
>> > I do not believe that has ever been the intent.
>>
>> Both descriptions of play() and pause() have a "loading the media
>> resource" in them.
>
> Yes, but not for the purpose of reloading, only for the purpose of loading
> the resource in the first place.
>
>
>> I assumed that if the @currentSrc had changed, that would trigger
>> loading the new media resource, too. If that is not the intention, maybe
>> the non-normative description should point out that it only triggers
>> loading the media resource when the @src attribute is being set for the
>> very first time.
>
> Well that's not quite accurate either... it does it if the networkState is
> NETWORK_EMPTY, which can happen in a variety of conditions. I'm open to
> changing this text (from "if necessary" which is what it says now) but I
> really don't know what to change it to that would be both accurate and
> helpful.
>
>
>> Though, to be honest, I don't really see a difference between setting
>> @src through JavaScript for the first time (which IIUC also has a
>> NETWORK_EMPTY state) and re-setting it again a subsequent time - IMHO
>> both should consistently either include the media resource loading or
>> exclude it.
>
> The difference is that the first time there's nothing loaded, so to play()
> anything you have to load it, whereas the second time there's already
> something loaded, which play() can just play straight away without having
> to load anything first.
>
>
>> On Tue, 27 Jul 2010, Silvia Pfeiffer wrote:
>> > >
>> > > Sure, but this is only a snippet of an actual application. If, e.g.,
>> > > you want to step through a list of videos (maybe an automated
>> > > playlist) using script and you need to provide at least two
>> > > different formats with <source>, you'd want to run this algorithm
>> > > frequently.
>> >
>> > Just have a bunch of <video>s in the markup, and when one ends, hide
>> > it and show the next one. Don't start dynamically manipulating
>> > <source> elements, that's just asking for pain.
>> >
>> > If you really must do it all using script, just use canPlayType and
>> > the <video src=""> attribute, don't mess around with <source>.
>>
>> Thanks for adding that advice. I think it's important to point that out.
>
> I can add it to the spec too if you think that would help. Where would a
> good place for it be?

There is a note in the <source> element section that reads as follows:
"Dynamically modifying a source element and its attribute when the
element is already inserted in a video or audio element will have no
effect. To change what is playing, either just use the src attribute
on the media element directly, or call the load() method on the media
element after manipulating the source elements."

Maybe you can add some advice there to use canPlayType to identify
what type of resource to add in the @src attribute on the media
element. Also, you should remove the last half of the second sentence
in this note if that is not something we'd like to encourage.

Cheers,
Silvia.
Received on Wednesday, 8 December 2010 16:12:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:02 UTC