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

I agree to what you're saying Bernard.

Though the point I tried to make was slightly different: AFAIK we are 
not describing anywhere what the MediaTrackSettings would read for a 
track sourced by a PeerConnection. Someone reading the WebRTC spec would 
just be directed to the mediacapture-main one, and there 
MediaTrackSettings are defined to include things like facingMode and so on.

I think we should add something in section 10.3 MediaStreamTrack.


On 23/02/16 22:05, 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
>
>

Received on Thursday, 25 February 2016 05:51:43 UTC