There may be reasons for addStream to fail (e.g the PeerConnection has been closed), but I don't think exhausting encoders is one of them. Any resources are not reserved until createOffer/setLocal. addStream simply adds the supplied stream to the list of local streams known to the PeerConnection. On Mon, Feb 25, 2013 at 2:08 PM, Harald Alvestrand <harald@alvestrand.no>wrote: > On 02/25/2013 10:13 PM, 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: >> >> 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). >> >> While we could allow these calls to succeed and then return an error when >> the application attempts to take further action (e.g., createOffer or >> createAnswer), I think delaying such errors until later will surprise and >> befuddle application developers. >> >> For these reasons, I would propose the addition of success and error >> callbacks to addStream. >> >> /a >> >> My standard questions for callbacks added to existing APIs: > > - Mandatory or optional? (we've preferred mandatory before) > - Before or after the optional "constraints" interface? > > And for curiosity - what were the plausible failures? > (I wasn't able to figure out a plausible failure for getStats either > before we implemented it and found one...) > > >Received on Tuesday, 26 February 2013 02:13:58 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:41 UTC