Re: Summary of replace track status

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