Re: Summary of replace track status

On Fri, May 22, 2015 at 5:51 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

>  On 5/22/15 6:09 PM, 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".
>
>
> Or hopefully "something I can do". I hope getting rid of SDP-renegotiation
> will mean getting rid of the need for it, rather than getting rid of what
> it provides. ;)
>
> +1 on replaceTrack not triggering renegotiation, since the whole reason
> for its existence is to avoid renegotiation. Therefore, people would
> probably rather it fail than trigger renegotiation, or they would have used
> addTrack/removeTrack. It's also easy enough to fall back to
> addTrack/removeTrack if so desired.
>

I don't agree with this conclusion. It violates POLA to have it fail like
this and is going to cause random, unpredictable failures in the field.

-Ekr


   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.
>
>  Thus, I think we can make a general rule of "If the application
> configures the RtpSender to do something impossible it either throws an
> exception or sends nothing".
>
>
> Certainly, RtpSender should not be required to do the impossible, but if
> you include anything requiring renegotiation in this, then I think that
> would need to be in the form of a proposal, since the spec says [1]:
>
> "When attributes on an RTCRtpSender are modified, the encoding is either
> changed appropriately, or a negotiation is triggered to signal the new
> encoding parameters to the other side."
>
> [1] http://w3c.github.io/webrtc-pc/#rtcrtpsender-interface
>
> .: Jan-Ivar :
>
>   On Fri, May 22, 2015 at 11:51 AM, Adam Roach <adam@nostrum.com> wrote:
>
>>  On 5/22/15 09:56, Stefan Håkansson LK wrote:
>>
>>> On 22/05/15 16:15, Peter Thatcher wrote:
>>> [...]
>>>
>>>>      * Detection/reporting of that negotiation would be needed: as said
>>>>      above, there seem to be consensus of that if the new track
>>>> (provided by
>>>>      replaceTrack) would require a re-negotiation, replaceTrack should
>>>> fail.
>>>>      How quickly can this be detected? How should it be reported back
>>>> to the
>>>>      application?
>>>>
>>>>
>>>> ​I don't recall of the top of my head any situation in which
>>>> replaceTrack could trigger a renegotiation.  Perhaps if we had some
>>>> scenarios were we thought that might come up, we could know how long it
>>>> would take to detect.  Does anyone have any concrete examples?
>>>>
>>> I agree, some concrete examples here would be helpful.
>>>
>>>
>>  Here's the easy example: I've started a session with a stream comes
>> from a USB camera with an on-chip H.265 encoder, so the codecs I've
>> indicated in my offer include H.265. The answer only indicated H.265 for
>> this stream.
>>
>> I have another stream, from a different source, which I cannot encode to
>> H.265 real-time. I call replaceTrack to swap this stream in for the H.265
>> stream. Unless we renegotiate the media line, this isn't going to work.
>>
>> /a
>>
>