Re: Summary of replace track status

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