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

RE: Summary of replace track status

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Tue, 26 May 2015 20:50:10 +0000
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, Shijun Sun <shijuns@microsoft.com>
Message-ID: <BLUPR03MB149FEEBE08A2BBCC4EA005FECCC0@BLUPR03MB149.namprd03.prod.outlook.com>
Stefan said: 

"after the dance there is a replaceTrack with a video source that does not encode to h265."

[BA] Looking through the Media Capture specification, I do not see mention of a track having an encoding constraint or codec attribute.    Can you point out to me where this is described? 

This leads me to one conclusion and one question.

Conclusion: replaceTrack should always fail (throw) if the signaling state is not stable (this was probably apparent to everyone else already).

[BA] Sure. 

Question: what would the sender's RtpParameters read out during the different stages of the dance if the app for some reason decides to check?

[BA] So far, I believe that the assumption is that RtpParameters are not changed (e.g. they remain as they were set).   If the RtpParameters are illegal, then an exception would result, but having the browser guess what was intended and change the value to match "what I think you meant" is problematic.  Plus, changing RtpParameters would probably imply the need for an event when they are changed.  So probably best not to go down that road unless it is absolutely necessary. 
Received on Tuesday, 26 May 2015 20:50:39 UTC

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