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

Re: Summary of replace track status

From: Adam Roach <adam@nostrum.com>
Date: Fri, 22 May 2015 13:51:16 -0500
Message-ID: <555F7AA4.5080005@nostrum.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Peter Thatcher <pthatcher@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 18:51:49 UTC

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