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

On 24/02/16 16:11, Harald Alvestrand wrote:
> 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?

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

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

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'.

>
> There are probably other things to consider...
>
>
>
>
>
>

Received on Wednesday, 24 February 2016 15:22:05 UTC