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

Re: New issue: switching sources

From: Peter Thatcher <pthatcher@google.com>
Date: Tue, 20 May 2014 09:17:34 -0700
Message-ID: <CAJrXDUG9heFUrsNv-aRR2E70HKRdiNB6m=0JzWK1w65J1EbcZQ@mail.gmail.com>
To: Jim Barnett <1jhbarnett@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
The idea is that the SDP is unchanged.  Only the source of the video frames
(or the audio) is changed.  If that is impossible for some reason, then the
UA could raise an error.


On Tue, May 20, 2014 at 9:14 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:

>  So is the idea that when switching tracks, the new one must match (all?,
> most?) of the SDP that described the old one?  Must the UA raise an error
> if it can't do so?
>
> On 5/20/2014 12:05 PM, Peter Thatcher wrote:
>
>  Ah, good point.  So via setLocalDescription and setRemoteDescription,
> the JS tells the browser to send codec X, but then tells it to send from
> source Y with hardware codec Z.  Well, in that case, I'd say do what the JS
> told the browser to do: send with codec X (without hardware encoding).
>  Yes, that is a danger and we should document it clearly if we decide to
> support this.
>
>
> On Tue, May 20, 2014 at 7:58 AM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> On 20 May 2014 07:27, Peter Thatcher <pthatcher@google.com> wrote:
>> > What do you mean by "understand the dangers"?  What dangers are there?
>>
>>
>>  Like the one where you have negotiated codec X and you switch in a
>> stream that is attached to a hardware encoder with only codec Y.
>>
>
>
> --
> Jim Barnett
> Genesys
>
Received on Tuesday, 20 May 2014 16:18:46 UTC

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