Video DOM API

[Gervase Markham-3]

On a <video> element (I haven't tried <audio>), if you change the src=
attribute to a new file, you have to call .load() before .play(),
otherwise it replays the old file. This lost me half an hour of
debugging, and recently another person posted in the Mozilla newsgroups
having exactly the same problem.

I am told by an informed source (Boris Zbarsky) that the spec for
<video> requires this behaviour. Having spent ten minutes reading the
highly comprehensive specification, I could not find the location where
it says this. However, I believe him :-)

Question: why? This is counter-intuitive. Under what circumstances would
you want to set the src= attribute of a <video> tag to a file which you
did not want the loading process to begin immediately? Can we eliminate
the requirement, e.g. by having play() implicitly call load() if it
hasn't been called?

Gerv

[Simon Pieters-3]

On Thu, 08 Oct 2009 13:14:37 +0200, Gervase Markham <gerv@...> wrote:

> On a <video> element (I haven't tried <audio>), if you change the src=  
> attribute to a new file, you have to call .load() before .play(),  
> otherwise it replays the old file. This lost me half an hour of  
> debugging, and recently another person posted in the Mozilla newsgroups  
> having exactly the same problem.
>
> I am told by an informed source (Boris Zbarsky) that the spec for  
> <video> requires this behaviour. Having spent ten minutes reading the  
> highly comprehensive specification, I could not find the location where  
> it says this. However, I believe him :-)

"If a src attribute of a media element that is in a Document and whose  
networkState has the value NETWORK_EMPTY is set or changed, the user agent  
must invoke the media element's resource selection algorithm."

If you have already played a video, networkState is not NETWORK_EMPTY, so  
the resource selection algorithm is not invoked (and thus play() will play  
the already-loaded video).


> Question: why? This is counter-intuitive. Under what circumstances would  
> you want to set the src= attribute of a <video> tag to a file which you  
> did not want the loading process to begin immediately? Can we eliminate  
> the requirement, e.g. by having play() implicitly call load() if it  
> hasn't been called?

Maybe we could remove the networkState check when the src attribute is set  
or changed. Should the "in a Document" check be removed, too? That is, do  
you want to be able to do

var a = new Audio('foo');
a.play();
a.onended = function() { a.src = 'bar'; a.onended = null; }

?

(You wouldn't need to invoke play() again, because the media isn't paused  
when it has ended.)

What do you think should happen when using <source> elements?

--
Simon Pieters
Opera Software

[Gervase Markham-3]

On 08/10/09 13:29, Simon Pieters wrote:
> Maybe we could remove the networkState check when the src attribute is
> set or changed. Should the "in a Document" check be removed, too? That
> is, do you want to be able to do
>
> var a = new Audio('foo');
> a.play();
> a.onended = function() { a.src = 'bar'; a.onended = null; }

That seems like the obvious way one would implement the chaining of
videos, isn't it? Although it doesn't allow for pre-loading and
therefore seamless linking unless you've loaded 'bar' in another <audio>
somewhere else previously. Hmm...

I think I want to be able to do:

var a = new Audio('foo');
a.play();
a.src = 'bar';
a.load();
a.onended = function() { a.play(); a.onended = null; }

which gives me the preloading as well without needing an extra element.

> What do you think should happen when using <source> elements?

Good question. I think that if I add a <source> element, it should be
automatically load()ed. But if I call play(), then the resource
selection algorithm should be used at that point to tell which video
actually plays.

Gerv

[Simon Pieters-3]

On Thu, 08 Oct 2009 14:53:59 +0200, Gervase Markham <gerv@...> wrote:

> On 08/10/09 13:29, Simon Pieters wrote:
>> Maybe we could remove the networkState check when the src attribute is
>> set or changed. Should the "in a Document" check be removed, too? That
>> is, do you want to be able to do
>>
>> var a = new Audio('foo');
>> a.play();
>> a.onended = function() { a.src = 'bar'; a.onended = null; }
>
> That seems like the obvious way one would implement the chaining of  
> videos, isn't it? Although it doesn't allow for pre-loading and  
> therefore seamless linking unless you've loaded 'bar' in another <audio>  
> somewhere else previously. Hmm...
>
> I think I want to be able to do:
>
> var a = new Audio('foo');
> a.play();
> a.src = 'bar';
> a.load();
> a.onended = function() { a.play(); a.onended = null; }
>
> which gives me the preloading as well without needing an extra element.

So you want the media element to load two resources at the same time? I'm  
very skeptical about this idea. What should happen when the user clicks  
pause and then play, should it suddenly switch to the new media?

I don't see the problem with having separate media elements for separate  
media:

var a1 = new Audio('foo');
var a2 = new Audio('bar');
a1.play();
a1.onended = function() { a2.play(); a1 = null; /* allow a1 to be garbage  
collected */ }

For video, you can do the same thing and just use replaceChild():

<video src='foo' autoplay controls></video>
<script>
var v1 = document.querySelector('video');
var v2 = document.createElement('video');
v2.autobuffer = true;
v2.controls = true;
v2.src = 'bar';
v2.load();
v1.onended = function() { v1.parentNode.replaceChild(v1, v2); }
</script>


>> What do you think should happen when using <source> elements?
>
> Good question. I think that if I add a <source> element, it should be  
> automatically load()ed. But if I call play(), then the resource  
> selection algorithm should be used at that point to tell which video  
> actually plays.

Not sure I follow. Currently, inserting a <source> into a media element  
that is in a document and has networkState NETWORK_EMPTY will run the  
resource selection algorithm. Inserting another <source> will only be used  
if the first <source> fails.

--
Simon Pieters
Opera Software

[Arthur Clifford]

Wouldn't it be easier to have play take an optional src parameter?

var a=new Audio();
a.onended = function() { if(a.src=='foo') a.play('bar'); }
a.play('foo');

internally play could do this check:
if( inSrc !== src) src=inSrc ... load and play video
else if at end of audio, rewind and play
else play forward from where the playback head is at.

Art C

-----Original Message-----
From: public-html-comments-request@...
[mailto:public-html-comments-request@...] On Behalf Of Gervase Markham
Sent: Thursday, October 08, 2009 5:54 AM
To: Simon Pieters; public-html-comments@...
Subject: Re: Video DOM API

On 08/10/09 13:29, Simon Pieters wrote:
> Maybe we could remove the networkState check when the src attribute is
> set or changed. Should the "in a Document" check be removed, too? That
> is, do you want to be able to do
>
> var a = new Audio('foo');
> a.play();
> a.onended = function() { a.src = 'bar'; a.onended = null; }

That seems like the obvious way one would implement the chaining of
videos, isn't it? Although it doesn't allow for pre-loading and
therefore seamless linking unless you've loaded 'bar' in another <audio>
somewhere else previously. Hmm...

I think I want to be able to do:

var a = new Audio('foo');
a.play();
a.src = 'bar';
a.load();
a.onended = function() { a.play(); a.onended = null; }

which gives me the preloading as well without needing an extra element.

> What do you think should happen when using <source> elements?

Good question. I think that if I add a <source> element, it should be
automatically load()ed. But if I call play(), then the resource
selection algorithm should be used at that point to tell which video
actually plays.

Gerv

[Musgrove, Jason L]

If what is being aimed for is the sequential playing of more than one
media item, why not amend the spec such that the appropriate media
element (either <audio> or <video>) be permitted to have child elements
that define a playlist in lieu of a src attribute (which can still be
used if only one media item is to played), and let the browser take care
of the sequencing without the unnecessary addition of script to do this.

Suggested example:

<video>
        <clip src="video1.m4v" />
        <clip src="video2.m4v" />
</video>

The API could then be augmented to include a ".clips" property which
represents a collection of the clip elements, and provides appropriate
methods to manipulate the "playlist".


-----Original Message-----
From: public-html-comments-request@...
[mailto:public-html-comments-request@...] On Behalf Of Arthur
Clifford
Sent: 08 October 2009 22:31
To: 'Gervase Markham'; 'Simon Pieters'; public-html-comments@...
Subject: RE: Video DOM API

Wouldn't it be easier to have play take an optional src parameter?

var a=new Audio();
a.onended = function() { if(a.src=='foo') a.play('bar'); }
a.play('foo');

internally play could do this check:
if( inSrc !== src) src=inSrc ... load and play video
else if at end of audio, rewind and play
else play forward from where the playback head is at.

Art C

-----Original Message-----
From: public-html-comments-request@...
[mailto:public-html-comments-request@...] On Behalf Of Gervase
Markham
Sent: Thursday, October 08, 2009 5:54 AM
To: Simon Pieters; public-html-comments@...
Subject: Re: Video DOM API

On 08/10/09 13:29, Simon Pieters wrote:
> Maybe we could remove the networkState check when the src attribute is
> set or changed. Should the "in a Document" check be removed, too? That
> is, do you want to be able to do
>
> var a = new Audio('foo');
> a.play();
> a.onended = function() { a.src = 'bar'; a.onended = null; }

That seems like the obvious way one would implement the chaining of
videos, isn't it? Although it doesn't allow for pre-loading and
therefore seamless linking unless you've loaded 'bar' in another <audio>

somewhere else previously. Hmm...

I think I want to be able to do:

var a = new Audio('foo');
a.play();
a.src = 'bar';
a.load();
a.onended = function() { a.play(); a.onended = null; }

which gives me the preloading as well without needing an extra element.

> What do you think should happen when using <source> elements?

Good question. I think that if I add a <source> element, it should be
automatically load()ed. But if I call play(), then the resource
selection algorithm should be used at that point to tell which video
actually plays.

Gerv


--
Scanned by iCritical.

[Arthur Clifford]

The clip tag idea is intriguing in that a clip could be audio, video, or an
image. If the clip tag supported optional 'delayBefore' and/or 'delayAfter'
attribute one could conceivably create an animation out of images, including
images of different types. The clips could also have a boolean 'preload'
attribute to indicate whether to load a clip when the video tag is
processed.

If the notion of a playlist is supported that would also mean the usual
playlist sorts of functions, next/back/repeat mode/playmode (i.e. shuffle,
sequential)



-----Original Message-----
From: public-html-comments-request@...
[mailto:public-html-comments-request@...] On Behalf Of Musgrove, Jason L
Sent: Thursday, October 08, 2009 3:25 PM
To: art@...; Gervase Markham; Simon Pieters;
public-html-comments@...
Subject: RE: Video DOM API

If what is being aimed for is the sequential playing of more than one
media item, why not amend the spec such that the appropriate media
element (either <audio> or <video>) be permitted to have child elements
that define a playlist in lieu of a src attribute (which can still be
used if only one media item is to played), and let the browser take care
of the sequencing without the unnecessary addition of script to do this.

Suggested example:

<video>
        <clip src="video1.m4v" />
        <clip src="video2.m4v" />
</video>

The API could then be augmented to include a ".clips" property which
represents a collection of the clip elements, and provides appropriate
methods to manipulate the "playlist".

[Gervase Markham-3]

On 08/10/09 15:45, Simon Pieters wrote:
> So you want the media element to load two resources at the same time?
> I'm very skeptical about this idea.

Actually, no, scratch that.

I just want play() to implicitly invoke load(), because then it all DWYM.

> Not sure I follow. Currently, inserting a <source> into a media element
> that is in a document and has networkState NETWORK_EMPTY will run the
> resource selection algorithm. Inserting another <source> will only be
> used if the first <source> fails.

I guess I'm not sure that the above change would affect this sort of
thing...

Gerv

[Simon Pieters-3]

On Fri, 09 Oct 2009 18:34:02 +0200, Gervase Markham <gerv@...> wrote:

> On 08/10/09 15:45, Simon Pieters wrote:
>> So you want the media element to load two resources at the same time?
>> I'm very skeptical about this idea.
>
> Actually, no, scratch that.
>
> I just want play() to implicitly invoke load(), because then it all DWYM.

Even if the first video hasn't ended yet? Even if src hasn't changed?

Invokind load() on play() still doesn't solve preloading, which you said  
you wanted to have earlier.

--
Simon Pieters
Opera Software

[Gervase Markham-3]

On 10/10/09 09:19, Simon Pieters wrote:
>> Actually, no, scratch that.
>>
>> I just want play() to implicitly invoke load(), because then it all DWYM.
>
> Even if the first video hasn't ended yet? Even if src hasn't changed?

Well, if src hasn't changed, then presumably load() is a no-op under any
circumstances?

If a video is playing, I change the src= and then call play() again, I
don't think it's unreasonable to expect the element to start playing the
new src.

> Invokind load() on play() still doesn't solve preloading, which you said
> you wanted to have earlier.

Yeah, scratch that. As you explained, much better to use two elements.

Gerv

[Simon Pieters-3]

On Sat, 10 Oct 2009 11:20:10 +0200, Gervase Markham <gerv@...> wrote:

> On 10/10/09 09:19, Simon Pieters wrote:
>>> Actually, no, scratch that.
>>>
>>> I just want play() to implicitly invoke load(), because then it all  
>>> DWYM.
>>
>> Even if the first video hasn't ended yet? Even if src hasn't changed?
>
> Well, if src hasn't changed, then presumably load() is a no-op under any  
> circumstances?

No. load() empties the media element, resets playbackRate, fires some  
events and restarts the resource selection algorithm.


> If a video is playing, I change the src= and then call play() again, I  
> don't think it's unreasonable to expect the element to start playing the  
> new src.

I think it is unreasonable, because pause() and play() are intended to be  
used for author-supplied scripted controls, and the user should be able to  
pause and play the first video without that causing the new video to be  
loaded.


>> Invokind load() on play() still doesn't solve preloading, which you said
>> you wanted to have earlier.
>
> Yeah, scratch that. As you explained, much better to use two elements.

Ok.

--
Simon Pieters
Opera Software

[Gervase Markham-3]

On 10/10/09 10:44, Simon Pieters wrote:
> I think it is unreasonable, because pause() and play() are intended to
> be used for author-supplied scripted controls, and the user should be
> able to pause and play the first video without that causing the new
> video to be loaded.

But then why has the app author set the src= element if they don't want
the new file to be the one that element is playing?

Here's the bottom line: I and at least one other person have been
confused by this API, because we expect

element.src = "file";
element.play();

to play "file". I don't think that's unreasonable, I think it's sensible
and intuitive. My feedback on the spec is: make that work. I don't care
how :-)

Gerv

[Philip Jägenstedt-2]

On Sat, 10 Oct 2009 12:02:42 +0200, Gervase Markham <gerv@...> wrote:

> On 10/10/09 10:44, Simon Pieters wrote:
>> I think it is unreasonable, because pause() and play() are intended to
>> be used for author-supplied scripted controls, and the user should be
>> able to pause and play the first video without that causing the new
>> video to be loaded.
>
> But then why has the app author set the src= element if they don't want  
> the new file to be the one that element is playing?
>
> Here's the bottom line: I and at least one other person have been  
> confused by this API, because we expect
>
> element.src = "file";
> element.play();
>
> to play "file". I don't think that's unreasonable, I think it's sensible  
> and intuitive. My feedback on the spec is: make that work. I don't care  
> how :-)

Making setting src implicitly call load() irrespective of the current  
state would have desired effect and as far as I can see there's little  
reason to think someone would set src without actually intending to use  
the resource. There would be nothing special about play(), doing nothing  
at all after setting src would also load the new resource, although it  
would initially be paused.

While this would probably be more intuitive, I don't quite see the use  
case for it if pre-buffering is important.

--
Philip Jägenstedt
Core Developer
Opera Software

[Arthur Clifford]

I would think that changing element.src would load and play unless
pre-buffering is enabled. If element is set to pre-buffer, then calling play
would be required after setting src. And calling play may not necessarily
need to be done immediately after src is set.

However, I think if you are going to have multiple audio clips playing back
to back that the idea someone mentioned a day or two ago makes more sense;
the idea of having a list of clip nodes that, in effect, is like having the
images array and the ability to preload images and dynamically swap image
sources at runtime via JS. Setting src on an img tag immediately displays
the image; should audio/video content be different? If a clip were preloaded
setting src to that clip would begin playing that clip, if it was not set to
preload it would load and play the clip as soon as you set the src of the
clip.

ArtC

[Michael A. Puls II]

Gervase Markham <gerv@...> wrote:

> On a <video> element (I haven't tried <audio>), if you change the src=
> attribute to a new file, you have to call .load() before .play(),
> otherwise it replays the old file. This lost me half an hour of
> debugging, and recently another person posted in the Mozilla newsgroups
> having exactly the same problem.

(Thanks for posting this)

I am that other person and here's what I personally expect, fwiw:

When setting src:

1. The current media should stop playing.

2. It should then be unloaded.

3. All states should be reset (including the play state).

4. The new media should start loading.

5. If autoplay is true, the new media should start playing. If not, it  
only starts playing when you call play().

My use-case is setting @src when clicking on a link (in an ordered list of  
many links with click handlers) to an .ogg file.

Having to call load() after setting src seems odd since I set src for a  
reason, which is, to load it so I can play() it (or automatically play it  
if I have autoplay set to true).

For <object> when you change @type/@data, the object is pretty much  
re-evaluated. I pretty much expect the same when setting src for <audio>  
and <video>

--
Michael

[Simon Pieters-3]

On Wed, 14 Oct 2009 06:12:01 +0200, Michael A. Puls II  
<shadow2531@...> wrote:

> Gervase Markham <gerv@...> wrote:
>
>> On a <video> element (I haven't tried <audio>), if you change the src=
>> attribute to a new file, you have to call .load() before .play(),
>> otherwise it replays the old file. This lost me half an hour of
>> debugging, and recently another person posted in the Mozilla newsgroups
>> having exactly the same problem.
>
> (Thanks for posting this)
>
> I am that other person and here's what I personally expect, fwiw:
>
> When setting src:
>
> 1. The current media should stop playing.
>
> 2. It should then be unloaded.
>
> 3. All states should be reset (including the play state).
>
> 4. The new media should start loading.
>
> 5. If autoplay is true, the new media should start playing. If not, it  
> only starts playing when you call play().
>
> My use-case is setting @src when clicking on a link (in an ordered list  
> of many links with click handlers) to an .ogg file.
>
> Having to call load() after setting src seems odd since I set src for a  
> reason, which is, to load it so I can play() it (or automatically play  
> it if I have autoplay set to true).
>
> For <object> when you change @type/@data, the object is pretty much  
> re-evaluated. I pretty much expect the same when setting src for <audio>  
> and <video>

What behavior do you expect when using <source>s instead of src?

--
Simon Pieters
Opera Software

[Ian Hickson]

On Thu, 8 Oct 2009, Gervase Markham wrote:

>
> On a <video> element (I haven't tried <audio>), if you change the src=
> attribute to a new file, you have to call .load() before .play(),
> otherwise it replays the old file. This lost me half an hour of
> debugging, and recently another person posted in the Mozilla newsgroups
> having exactly the same problem.
>
> I am told by an informed source (Boris Zbarsky) that the spec for
> <video> requires this behaviour. Having spent ten minutes reading the
> highly comprehensive specification, I could not find the location where
> it says this. However, I believe him :-)
>
> Question: why? This is counter-intuitive. Under what circumstances would
> you want to set the src= attribute of a <video> tag to a file which you
> did not want the loading process to begin immediately? Can we eliminate
> the requirement, e.g. by having play() implicitly call load() if it
> hasn't been called?

I've made setting .src stop the video and reload as you request.

It doesn't affect <source> processing, though.


On Thu, 8 Oct 2009, Simon Pieters wrote:

>
> Maybe we could remove the networkState check when the src attribute is
> set or changed. Should the "in a Document" check be removed, too? That
> is, do you want to be able to do
>
> var a = new Audio('foo');
> a.play();
> a.onended = function() { a.src = 'bar'; a.onended = null; }
>
> ?
>
> (You wouldn't need to invoke play() again, because the media isn't
> paused when it has ended.)

It calls load(), so you do have to do the check.


On Sat, 10 Oct 2009, Simon Pieters wrote:
> On Fri, 09 Oct 2009 18:34:02 +0200, Gervase Markham <gerv@...>
> wrote:
> >
> > I just want play() to implicitly invoke load(), because then it all
> > DWYM.
>
> Even if the first video hasn't ended yet? Even if src hasn't changed?

On Sat, 10 Oct 2009, Gervase Markham wrote:
>
> Well, if src hasn't changed, then presumably load() is a no-op under any
> circumstances?

load() always restarts the entire loading algorithm.


> If a video is playing, I change the src= and then call play() again, I don't
> think it's unreasonable to expect the element to start playing the new src.

play() maps to the play button in the UI. So if made it wait until play()
was called, then the script could change the src, not call play(), and
then the user would find that if he hit pause and then play again, it
would suddenly load the new video. That would be rather weird.


On Thu, 8 Oct 2009, Arthur Clifford wrote:

>
> Wouldn't it be easier to have play take an optional src parameter?
>
> var a=new Audio();
> a.onended = function() { if(a.src=='foo') a.play('bar'); }
> a.play('foo');
>
> internally play could do this check:
> if( inSrc !== src) src=inSrc ... load and play video
> else if at end of audio, rewind and play
> else play forward from where the playback head is at.

We could do that, but that would be redundant with setting src="" (which
we can't really remove), so I don't see much point.


On Thu, 8 Oct 2009, Musgrove, Jason L wrote:

>
> If what is being aimed for is the sequential playing of more than one
> media item, why not amend the spec such that the appropriate media
> element (either <audio> or <video>) be permitted to have child elements
> that define a playlist in lieu of a src attribute (which can still be
> used if only one media item is to played), and let the browser take care
> of the sequencing without the unnecessary addition of script to do this.
>
> Suggested example:
>
> <video>
> <clip src="video1.m4v" />
> <clip src="video2.m4v" />
> </video>
>
> The API could then be augmented to include a ".clips" property which
> represents a collection of the clip elements, and provides appropriate
> methods to manipulate the "playlist".

Playlists are on the cards for v2.


On Wed, 14 Oct 2009, Michael A. Puls II wrote:

>
> I am that other person and here's what I personally expect, fwiw:
>
> When setting src:
>
> 1. The current media should stop playing.
>
> 2. It should then be unloaded.
>
> 3. All states should be reset (including the play state).
>
> 4. The new media should start loading.
>
> 5. If autoplay is true, the new media should start playing. If not, it
> only starts playing when you call play().

That is now the case.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Michael A. Puls II]

On Wed, 14 Oct 2009 04:25:42 -0400, Simon Pieters <simonp@...> wrote:

> On Wed, 14 Oct 2009 06:12:01 +0200, Michael A. Puls II  
> <shadow2531@...> wrote:
>
>> Gervase Markham <gerv@...> wrote:
>>
>>> On a <video> element (I haven't tried <audio>), if you change the src=
>>> attribute to a new file, you have to call .load() before .play(),
>>> otherwise it replays the old file. This lost me half an hour of
>>> debugging, and recently another person posted in the Mozilla newsgroups
>>> having exactly the same problem.
>>
>> (Thanks for posting this)
>>
>> I am that other person and here's what I personally expect, fwiw:
>>
>> When setting src:
>>
>> 1. The current media should stop playing.
>>
>> 2. It should then be unloaded.
>>
>> 3. All states should be reset (including the play state).
>>
>> 4. The new media should start loading.
>>
>> 5. If autoplay is true, the new media should start playing. If not, it  
>> only starts playing when you call play().
>>
>> My use-case is setting @src when clicking on a link (in an ordered list  
>> of many links with click handlers) to an .ogg file.
>>
>> Having to call load() after setting src seems odd since I set src for a  
>> reason, which is, to load it so I can play() it (or automatically play  
>> it if I have autoplay set to true).
>>
>> For <object> when you change @type/@data, the object is pretty much  
>> re-evaluated. I pretty much expect the same when setting src for  
>> <audio> and <video>
>
> What behavior do you expect when using <source>s instead of src?
>

Well, you can insert, replace and remove a <source> element. You can  
change @src and @type on each <source> that's present.

One easy way (thought-wise) to handle that is that whenever any of that  
happens, the UA should stop, unload, reset states and figure out what  
<source> to play.

On the other hand, you might want to change @src for multiple <source>s  
without triggering a reevalutation until you explicitly call for one.

Or, you might want a mix of the two that depends on whether there's just  
one <source> or where you're inserting a <source> (before the one that's  
currently being used for example) or which <source> you're removing (the  
one being used or not).

So, I mostly expect the first way. However, the second seems simpler and  
would just cover everything.

But, note that I haven't really dealt with the multiple type fallback  
stuff yet, so I don't have a strong opinion on <source> yet.

--
Michael

[Michael A. Puls II]

On Wed, 14 Oct 2009 04:54:57 -0400, Ian Hickson <ian@...> wrote:

> On Wed, 14 Oct 2009, Michael A. Puls II wrote:
>>
>> I am that other person and here's what I personally expect, fwiw:
>>
>> When setting src:
>>
>> 1. The current media should stop playing.
>>
>> 2. It should then be unloaded.
>>
>> 3. All states should be reset (including the play state).
>>
>> 4. The new media should start loading.
>>
>> 5. If autoplay is true, the new media should start playing. If not, it
>> only starts playing when you call play().
> That is now the case.

Thanks

--
Michael

[Simon Pieters-3]

On Wed, 14 Oct 2009 12:11:27 +0200, Michael A. Puls II  
<shadow2531@...> wrote:

>> What behavior do you expect when using <source>s instead of src?
>>
>
> Well, you can insert, replace and remove a <source> element. You can  
> change @src and @type on each <source> that's present.

Also keep in mind that the parser inserts <source> elements.


> One easy way (thought-wise) to handle that is that whenever any of that  
> happens, the UA should stop, unload, reset states and figure out what  
> <source> to play.

The resource selection algorithm tries each <source> in turn. It seems bad  
to start over several times during parsing.


> On the other hand, you might want to change @src for multiple <source>s  
> without triggering a reevalutation until you explicitly call for one.

Indeed.

> Or, you might want a mix of the two that depends on whether there's just  
> one <source> or where you're inserting a <source> (before the one that's  
> currently being used for example) or which <source> you're removing (the  
> one being used or not).
>
> So, I mostly expect the first way. However, the second seems simpler and  
> would just cover everything.
>
> But, note that I haven't really dealt with the multiple type fallback  
> stuff yet, so I don't have a strong opinion on <source> yet.

--
Simon Pieters
Opera Software