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

Re: MediaStreams and Media elements

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Thu, 30 May 2013 08:14:32 +0200
Message-ID: <51A6EE48.5030106@ericsson.com>
To: robert@ocallahan.org
CC: Jim Barnett <Jim.Barnett@genesyslab.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-05-29 02:32, Robert O'Callahan wrote:
> On Wed, May 29, 2013 at 7:35 AM, Jim Barnett <Jim.Barnett@genesyslab.com
> <mailto: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.

This sounds very reasonable to me.

/Adam
Received on Thursday, 30 May 2013 06:15:00 UTC

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