- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 30 May 2013 08:14:32 +0200
- 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