Re: MediaStreams and Media elements

On 5/31/13 4:39 PM, Jim Barnett wrote:
> 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.

Running this via Travis is probably a good idea. And that the behavior 
defined is close to what we want is encouraging.

>
> - 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 Saturday, 1 June 2013 07:20:44 UTC