W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: asynchrony for addStream w/ error/success callbacks

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sun, 12 Jan 2014 09:45:55 +0000
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C4395FB@ESESSMB209.ericsson.se>
On 12/01/14 02:07, Silvia Pfeiffer wrote:
> On Sun, Jan 12, 2014 at 12:12 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> On 2014-01-10 18:38, Martin Thomson wrote:
>>> On 10 January 2014 01:13, Stefan Håkansson LK
>>> <stefan.lk.hakansson@ericsson.com> wrote:
>>>> I may be wrong...
>>> :)
>>>
>>> I was planning to propose a change to the API that would necessitate
>>> an error on addStream.  More on that later, it requires a better
>>> explanation than I want to hide on this thread.
>>
>> Looking forward to it (and I sort of hope it will be addTrack rather
>> than addStream)!
>
> Just be aware: there's already an onaddtrack event in HTML5:
> http://www.w3.org/TR/html5/embedded-content-0.html#handler-texttracklist-onaddtrack

Yes, and as I understand it the MediaStreams and MediaStreamTracks have 
been designed with that in mind.

> .
>
> Cheers,
> Silvia.
>
>> But, without going into details, the current discussion seems to evolve
>> around when the check of whether or not there are resources available to
>> actually transmit the tracks of the added stream or not is carried out
>> at addStream time, or later (createOffer); and how the application gets
>> to know about that a track can not be sent (is it at addStream, by an
>> event fired on the DooHickey, or by polling the stats API).
>>
>> I am fine with any way - but it is clear we need to agree.
>>
>> And I would argue that having that error at addStream is not that
>> helpful, because things can change later. Say you addStream, and then
>> add one more track to the MediaStream (this was really another argument
>> why we should addTrack rather than addStream to PeerConnection). Or say
>> you change resolution and framerate on a track being sent by working
>> with the Constraints of that track, and now the PeerConnection can't
>> handle it any more. And some people have been pointing out the CPU clock
>> may be lowered in frequency due to overheating at any time.
>>
>> Stefan
>>
>
Received on Sunday, 12 January 2014 09:46:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC