Re: asynchrony for addStream w/ error/success callbacks

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