Re: MediaStreams and Media elements

On Thu, May 30, 2013 at 2:01 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

> >> Is there an 'ended' event for media elements?


Yes.

Again I agree to Rob. If the connection goes down (so that a remote
> MediaStream stops) the application will get to know from PeerConnection
> events, and deal with it there.
> >> So nothing needs to be signaled at the media element level?  It will be
> as if the connection dropped while the element was playing streaming media.
>

If the stream has terminated, then the media element should enter the ended
state.

We could give MediaStreams separate "finished with no error" and "finished
with error" states, and then allow a media element to respond to a
"finished with error" state by entering its own error state, but that seems
unnecessary.

So I think you could attach an empty MediaStream to a media element,
> than as tracks are added to the MediaStream they would be detected by
> the media element.
>
> >> If we're lucky.  The problem I have is that the prose you quote above
> is _inside_ the resource fetch algorithm.  And that algorithm can terminate
> in a number of places for a wide variety of reasons.  It would be equally
> plausible for the UA to assume that the empty MediaStream was unplayable
> data and terminate.  The whole load algorithm is so sprawling and
> disjointed that it is hard to say what it would do with a MediaStream
> (which doesn't need to be fetched at all.)  It also makes it hard to modify
> it cleanly.  Perhaps the best thing to do is to say:
> 1.  If the MediaStream contains one or more Tracks, treat it as a fully
> downloaded file (that's what the current prose does.)
> 2.  Otherwise (i.e., if the MediaStream is empty) wait (for a
> platform-specific interval) for one or more Tracks to be added, then treat
> it as a fully downloaded file.
> Both these clauses will cause the load algorithm to terminate, and Tracks
> added after the algorithm terminates will not  be detected until the next
> time load() is called.  (This shouldn't be a problem for developers, as
> long as they understand that this is what will happen.)
>

This seems unnecessarily restrictive. I agree with Stefan, there is no
reason to prevent dynamic changes to the track list of a MediaStream being
reflected in media elements consuming that stream.

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"