W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2015

Re: Summary of replace track status

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 22 May 2015 15:09:55 -0700
Message-ID: <CAJrXDUEG6dZh3H1Z0hEceVwiduU6FC=q7Fg7LJWDcd-MNNGFXQ@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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.

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".



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
>
Received on Friday, 22 May 2015 22:11:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC