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

> https://github.com/w3c/webrtc-pc/pull/519

The text in the PR isn't quite right because the RtpSender and RtpReceiver are in somewhat different situations. While O/A affects the settings of both objects, RtpSender parameters can be set via setParameters() whereas there is no equivalent method for the RtpReceiver. Therefore the RtpReceiver track properties are determined by the remote party whereas properties of what is sent by the RtpSender is more under local control.

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

[BA] That is factual, so reasonable to put in.

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

[BA] Yes, we do need text on that.

>> 
>> Something like
>> 
>> The sender SHOULD choose a codec configuration that will produce a
>> representation reasonably close to what is returned by
>> track.getSettings() in terms of width, height and framerate for video,
>> and sample rate and latency for audio.
> 
> I like your this better than what is in the PR, I'll update based on 
> that, and add a section (that about "width etc. are initialized to 
> values observed...") to '10.3 MediaStreamTrack'.

[BA] I would prefer to better define how the settings behave, because there are quite a few situations where they will not produce video close to track.getSettings(). Setting resolutionScaleDownBy to a value other than 1.0, maxFramerate < track.frameRate, etc. are some examples.

Received on Wednesday, 24 February 2016 15:59:14 UTC