RE: MediaStreams and Media elements

As I read the resource fetch algorithm in the HTML5 spec (which is with great difficulty), I think that if the media element loads a resource with no playable tracks, it will raise an error.  If the resource was specified by the 'src' attribute, it will then stop (until the 'src' value is changed or load() is called again.)  If the resource was specified by a <source> element, the UA will still signal the error, but will proceed to the next <source> element.  

If we follow this logic, the behavior with a MediaStream with no Tracks (or unplayable Tracks) will depend on whether it was specified by direct assignment or src (on one hand) or by <source> (on the other hand.)  In the former case, the media element will raise an error and stop trying to load anything.  In the latter case, it will raise an error and go on to the next <source> element.  

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Thursday, May 30, 2013 2:15 AM
To: robert@ocallahan.org
Cc: Jim Barnett; public-media-capture@w3.org
Subject: Re: MediaStreams and Media elements

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 15:00:46 UTC