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

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.

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").

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:47:05 UTC