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: Sat, 11 Jan 2014 13:12:06 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C4373DD@ESESSMB209.ericsson.se>
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)!

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.

Received on Saturday, 11 January 2014 13:12:31 UTC

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