Re: Relation between a track's constraints/settings and how it is transmitted

On 19/01/16 16:16, Bernard Aboba wrote:
> On Jan 19, 2016, at 1:49 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>>
>> It seems to me that it would be logical for a web author to expect,
>> if a  video track is constrained to e.g. a certain width, height
>> and framerate, the UA to try (of course there are situations when
>> it is not possible to fulfill the constraints - there may be
>> network congestion or CPU limitations for example) to honor this if
>> the track is transmitted to a peer using PeerConnection.
>
> [BA] Constraints are applied to the track before it is input to the
> encoder. The encoder guidance is provided in
> RTCRtpEncodingParameters. This includes
> parameters.degradationPreference,
> parameters.encodings[j].resolutionScaleDownBy, maxFramerate, etc.
>
> So I think you are asking about default values of the encoding
> parameters.

I was actually at the step before. You are right in that constraints are 
applied on the track before it is input to the encoder. But I see no 
text saying that what the encoder does (and what is the characteristics 
of the track at the remote endpoint) does have to comply to that in any way.

Just as an example: let's say I constrain a local track to height 1080 
and framerate 60. There is (as I read the spec) no text saying the 
encoder should encode something that can be decoded to 1080@60; the UA 
could at its discretion - even if it has a good network connection and a 
lot of resources - encode to 360@15. And we have no "overconstrained" 
event to tell the app (even though I guess it can find out from the stats).

So my question was basically if we should have text saying the UA should 
(try to) honor the track constraints when setting up encoders.

>

Received on Tuesday, 19 January 2016 15:38:31 UTC