RE: MediaStreams and Media elements

Travis is an editor of HTML5, perhaps we can ask him to bring up the issue for us.  I think it's best if we come up with a way to map MediaStreams onto the current algorithm, though.  The key with a MediaStream is that it is potentially unbounded, so the algorithm never leaves the resource fetch phase (unless there's some sort of fatal error).  If that's the case, then the algorithm will detect and add new Tracks.  A MediaStream without any Tracks would be like a resource that was slow loading.  After 3 seconds, the UA will fire the stalled event, but will continue waiting until either the user cancels the load or the UA itself gives up (because of some platform-specific limit).  That sounds close to the behavior we want, but it would  be good to get the HTML group's opinion on how to map it onto the existing spec.

- Jim

-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Friday, May 31, 2013 10:03 AM
To: public-media-capture@w3.org
Subject: Re: MediaStreams and Media elements

Maybe we should not spend too much time trying to fully understand the resource fetch algo. It is difficult to parse.

Perhaps it would be better if we agreed on how we think it should work in this specific case, and then tell the html WG that this is how we think it should work and ask if that is in line with what they have specced (perhaps asking for clarifications).

I would like it to work the following way:

* If a MediaStream with no tracks is attached to a media element, there should be no error events fired (but of course nothing is played - there is no content)
* Whenever tracks are added to that MediaStream they are detected by the media element (adding them to the Audio/VideoTrackList and firing addtrack events).

Br,
Stefan

On 2013-05-31 15:41, Jim Barnett wrote:
> Then what is the applicable  clause?  Do we treat it as a failure to
> fetch any data at all?  If that’s  the case, I think that the same logic
> still applies:
>
> /If the media data
> <http://www.w3.org/TR/html5/embedded-content-0.html#media-data> cannot
> be fetched at all, due to network errors, causing the user agent to give
> up trying to fetch the resource/
>
> /If the media data
> <http://www.w3.org/TR/html5/embedded-content-0.html#media-data> can be
> fetched but is found by inspection to be in an unsupported format, or
> can otherwise not be rendered at all/
>
> /DNS errors, HTTP 4xx and 5xx errors (and equivalents in other
> protocols), and other fatal network errors that occur before the user
> agent has established whether the /current media resource/is usable, as
> well as the file using an unsupported container format, or using
> unsupported codecs for all the data, must cause the user agent to
> execute the following steps:/
>
> /1.//The user agent should cancel the fetching process./
>
> /2.//Abort this subalgorithm, returning to the resource selection
> algorithm
> <http://www.w3.org/TR/html5/embedded-content-0.html#concept-media-load-algorithm>./
>
> //
>
> Jim
>
> *From:*rocallahan@gmail.com [mailto:rocallahan@gmail.com] *On Behalf Of
> *Robert O'Callahan
> *Sent:* Friday, May 31, 2013 9:31 AM
> *To:* Jim Barnett
> *Cc:* Adam Bergkvist; public-media-capture@w3.org
> *Subject:* Re: MediaStreams and Media elements
>
> I don't think your first quotatoin applies to the case where a resource
> is in a known format but has no playable tracks. Possibly "cannot be
> rendered at all" could be interpreted to include the case of no playable
> tracks, but I don't read it that way.
>
> 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"
>

Received on Friday, 31 May 2013 14:39:24 UTC