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

On 02/24/2016 03:56 PM, Stefan Håkansson LK wrote:
>> > 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.

Aha - I interpreted the subject line wrong.
Better to refer to the PR by number?
>
>> >
>> > 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.
>

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.

There are probably other things to consider...

Received on Wednesday, 24 February 2016 15:11:06 UTC