RE: [webrtc-pc] Plan X: Add an API for using RID to do simulcast (#353)

Actually in your example it’s working as I’d like: they’re both with a frame rate lower than the max framerate I asked for!

Constraints on the stream don’t work in the simulcast case as it would constrain all encodings.

The reasoning for having a maxFramerate (possibly in addition to scaleBy, which is what I remember we actually converged to), is that for screen sharing, you wouldn’t want to skip every other slide if you have a framerateScale of 2. A max framerate encoding parameter allows you to produce a simulcast encoding that include all content captured but with a lower update frequency when the source spikes in framerate (transition, video playing, etc.)

Similarly consider you have a webcam that runs at 30fps normally, and you have an encoding with scaleFramerateBy 15 to produce a low frequency “preview” version. Now the light conditions in the room change and the camera suddenly generates only 5fps, I do not want my “preview” encoding to only update every 3 seconds instead of twice per second as I’d have with a maxFramerate constraint.


From: Bernard Aboba []
Sent: Wednesday, November 4, 2015 16:44
Subject: Re: [webrtc-pc] Plan X: Add an API for using RID to do simulcast (#353)

Are we now using github for discussions relating to WG consensus??

The problem with maxFramerate is that it can result in two simulcast streams with the same frame rate - which is the reason why track cloning doesn't work.

For example, setting maxFramerate on one stream to 7.5 and another to 15 does not work if the frame rate coming from the camera is < 7.5.

In fact one could argue that there is no need for maxFramerate in the encoding parameters at all - just use constraints if that's what you want.

On Nov 4, 2015, at 7:29 PM, Mathieu Hofman <<>> wrote:

I thought we converged to agreeing maxFramerate was enough, and that a framerateScale might be weird for source with variable framerate, e.g. screensharing.

As an application developer, max-framerate is what I want.

Reply to this email directly or view it on GitHub<>.

Received on Thursday, 5 November 2015 01:07:45 UTC