W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2013

Re: MediaStreams and Media elements

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 29 May 2013 12:32:33 +1200
Message-ID: <CAOp6jLZ1eKzc+pNxn8dV3w7UFq9T8=b_hMjDwddzhTi0k721yg@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On Wed, May 29, 2013 at 7:35 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>  3.       What happens if the MediaStream that is fetched has ended =
> true?   Should we silently continue to use the dead stream and let HTML5
> figure out what to do, or should we raise an error?  In the latter case,
> the HTML5 spec defines a MediaError  Media_ERR_Aborted , which we might be
> able to use.  It is defined as “The fetching process for the media
> resource<http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#media-resource>was aborted by the user agent at the user's request.”  Isn’t  that sort of
> what happens when a local MediaStream is ended?

I think it should fire an "ended" event, not an error.

> **4.       **Do we want to say anything about remote MediaStreams?  In
> the case of a local MediaStream, NETWORK_IDLE makes sense for the
> networkState, because there is no network traffic.  But for a remote stream
> the NETWORK_LOADING state might be relevant.  On the other hand, the  Media
> Capture spec seems implicitly to deal with local streams (created by gUM).
> If we want to explicitly allow remote streams, we have to explain how they
> are created, etc.   I suppose we could  say that streams can be remote, but
> the method of creating such a stream is outside the scope of this spec.
> But then we’d at least have to say how the UA determines if a MediaStream
> is local or remote.

I don't think we should try to propagate network state from a MediaStream
into the MediaElement. It's OK to make the element's network state only
reflect the state of its own loads.

> ****
> **5.       **What do we say if a MediaStream with no Tracks is passed to
> a media element (i.e., in the fetch phase of the algorithm)?  Do we treat
> this as if the media element had fetched unplayable data? There is a *
> MEDIA_ERR_SRC_NOT_SUPPORTED*  that we could  use in this case.  Or is it
> another Media_ERR_Aborted?  The fetch algorithm checks for the presence of
> audio and video tracks at a certain point, and any Tracks added after that
> won’t be detected  (until load() is called again.)

I think it should behave just like it would if the media element loaded a
resource with no playable tracks. I think that means no error is thrown,
but I'm not sure.

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 Wednesday, 29 May 2013 00:33:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:17 UTC