Re: [Bug 21618] New: MediaStreams with no tracks need to not be Ended

On Tue, May 28, 2013 at 9:30 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On 05/28/2013 11:13 AM, Robert O'Callahan wrote:
>
> On Tue, May 28, 2013 at 9:04 PM, Harald Alvestrand <harald@alvestrand.no>wrote:
>
>> So a stream will un-end itself if one adds a live track to it. I can live
>> with that.
>>
>
>  I'm not happy with that for the reasons in my message of April 9.
>
> Rob, this message?
>

Yes.


> I thought we determined that it's possible for a MediaElement to exit its
> ended state if either the playing position was set or the direction changed
> (which can happen under JS control) - so it's consistent with MediaElement
> to have a transition from ended to not-ended because of things that JS does
> to the underlying object.
>

Yes, the control APIs on a media resource can be used to resume playback,
but the media resource itself can't suddenly un-end. Nothing defines how
that would affect the media element state, which events would fire on the
media element, etc. And it's just weird.

Having said that, apparently Media Source Extensions is currently specced
to allow something similar. I don't like that either, and it is just as
poorly specified as the situation we have here.

If we're going to do this, the HTML5 media element spec needs to be
extended with to describe how media elements react to their resources
suddenly growing after having ended. Or actually, given that both
MediaStreams and Media Source Extensions fail to describe in detail how
media elements reaact to changes in these source objects, maybe we should
tackle that head on.

Rob
-- 
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

Received on Tuesday, 28 May 2013 10:09:48 UTC