- From: Justin Uberti <juberti@google.com>
- Date: Tue, 14 Jan 2014 11:33:41 -0800
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOJ7v-2pDpqVNseorpjSXEYTKCPsRPRX4z3EkXtL4sNXpO6R-w@mail.gmail.com>
I agree with Stefan. Hardware encoders typically are limited by pixel rate as opposed to just a number of streams, so a successful AddStream is no guarantee of success (or vice versa) when we allow constraints on the track/doohickey to be mutated later. Ergo, I think we should keep AddStream/Track with the "add-to-cart" semantics mentioned by Jan-Ivar. On Sat, Jan 11, 2014 at 5: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)! > > 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 Tuesday, 14 January 2014 19:34:29 UTC