- 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>
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. Stefan
Received on Saturday, 11 January 2014 13:12:31 UTC