Re: What track settings are carried over a peer connection?

On 24/02/16 15:47, Harald Alvestrand wrote:
> On 02/23/2016 10:05 PM, Bernard Aboba wrote:
>> While characteristics such as width, height, framerate may be conveyed by the negotiated video codec, these are not track properties, but rather properties of the encoded video.
>>
>> Also, it is not necessarily the case that either track or encoder properties will be symmetric.  For example, a mobile device might be able to capture or encode at higher framerate and resolution than it is capable of decoding or rendering.
>>
>> So my take is that if the developer desires to transmit various track properties to the remote peer, this would be best done by explicitly sending them over the data channel.
>>
>> -----Original Message-----
>> From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>> Sent: Tuesday, February 23, 2016 5:25 AM
>> To: webrtc-editors@alvestrand.no
>> Subject: What track settings are carried over a peer connection?
>>
>> Hi,
>>
>> I'm working on the PR that says the "characteristics such as width, height, framerate and so on" should be carried over a PeerConn (i.e.
>> that the remote track should have similar characteristics as the one being sent). This can be expressed in terms of MediaTrackSettings, but it made me wonder:
>>
>> Have we documented somewhere what the MediaTrackSettings should read out for a track sourced by a PeerConnection.
>>
>> Things like width, height, framerate seems straightforward, but what about things like facingMode, echoCancellation, latency? That should
>> (is?) be documented somewhere.
>>
>> Stefan
>>
>>
> I'm thinking that this text is an example of wishful thinking, and we
> shouldn't say it.

I guess you're referring to the text in the PR.

If you think we should not say that, what should we say?

We have had some debate about avoiding duplicate controls, meaning that 
if you can define something as a track property (using constraints) we 
should not have the same things controllable on the sender. But if the 
implementation should not pay any attention to how a track is 
constrained that all goes away. And there would be no way of doing e.g. 
poor mans simulcast.

>
> Instead, we could say something like:
>
> Width, height and framerate for the remote track are initialized to the
> values observed on the incoming video, and are made available through
> getSettings(). Properties that cannot be deduced from the remote
> description and the incoming media stream are left at their default
> value (normally "unset").

I think we should say that too (and the corresponding stuff for audio), 
but I was after adding text about how the sender acts.

>
> The track ID and stream ID are set from the MSID of the incoming track,
> which is available from the remote description.
>
>
>
>
>
>

Received on Wednesday, 24 February 2016 14:56:42 UTC