- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Tue, 26 Feb 2013 08:22:54 +0100
- 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