- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Sat, 23 May 2015 07:00:29 +0000
- To: Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 23/05/15 00:10, Peter Thatcher wrote: > Thank you for the example. > > I don't view that as "needs renegotiation" as much as "the RtpSender was > configured to send in a codec it's not capable of sending". Once we, > someday, have direct control of RtpSenders (sans SDP), the browser > would basically view this as "JS told me to do something I can't do". > And if you view SetLocalDescription/SetRemoteDescription as a very poor > API for controlling RtpSenders (which, in reality, it is), then this is > also a case of "JS told me to do something I can't". And all the > browser can do is either throw an exception or send nothing. A concrete example to see if I get this right: Assume that the app does addTrack with a video track coming from a camera with built in possibility to encode to h265 (but also being capable of supplying some "rawer" format). Assume also that the browser can encode to VP8 and h264, so the browser can send h264, h265 and VP8 to a peer for this camera. And, assume the app does not touch the RtpSender settings. We then have a createOffer/setLocal/....getting an answer/setRemote dance, and the answer says "h265 only". Somehwere during or (most likely) after the dance there is a replaceTrack with a video source that does not encode to h265. This leads me to one conclusion and one question. Conclusion: replaceTrack should always fail (throw) if the signaling state is not stable (this was probably apparent to everyone else already). Question: what would the sender's RtpParameters read out during the different stages of the dance if the app for some reason decides to check?
Received on Saturday, 23 May 2015 07:00:57 UTC