W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2013

Re: Another API issue: addStream has no callbacks

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 26 Feb 2013 08:22:54 +0100
Message-ID: <512C62CE.2060402@ericsson.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
CC: public-webrtc@w3.org
On 2013-02-26 07:33, Stefan Håkansson LK wrote:
> On 2013-02-25 22:13, Adam Roach wrote:
>> Sometimes it seems like I'm screaming into the void by posting the
>> issues we're actually running into implementing this stuff, but here's
>> another problem we've uncovered with the currently defined API:
>
> Sorry to hear that you feel you're screaming into the void. If there are
> other issues related to implementation you have raised but feel weren't
> addressed, please send a new mail to the list.
>
>>
>> addStream() can plausibly fail, and some of those failures can occur
>> asynchronously. Examples of such failures include exhausting encoders of
>> the indicated type (e.g., I might have a device with only one hardware
>> video encoder).
>
> As said by Harald and Justin already, when we moved from ROAP to JSEP,
> addStream also stopped doing anything (except telling the PeerConnection
> that the added stream would be considered at next
> createOffer/Answer+setLocal), I think that is the reason why we've
> considered that there would be no errors.
>
> If you have discovered that this does not hold, we should redesign. Can
> you elaborate a bit more on the possible errors?
>
> Also, we have the situation when "addTrack" is done to a MediaStream
> that is already attached to one or more PeerConnections. I figure that
> similar errors could happen here, and we need to handle them as well.

Good point. My first thought around this is that if a MediaStream 
consumer runs into trouble when a track is added to a stream, then the 
problem should be reported at the consumer and not the stream. There may 
be several consumers of that stream.

/Adam
Received on Tuesday, 26 February 2013 07:23:19 UTC

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