Re: A Big Proposal: A way to control quality/resolution/framreate/simulcast/layering with RtpSender

On Wed, Feb 19, 2014 at 3:52 PM, Martin Thomson <martin.thomson@gmail.com>
 wrote:

> On 19 February 2014 15:44, Peter Thatcher <pthatcher@google.com> wrote:
> > I think we still need scale for simulcast and maxBitrate for cases where
> you
> > want to constrain bandwidth even when it's available.    And priority vs.
> > resources seems pretty similar.
>
>
> I'd like to take simulcast out actually.  I think that aside from some
> bindings necessary to get playback right, you can achieve simulcast
> transmission (what we are talking about here) by having multiple
> tracks with different resolution constraints.  I don't think that
> means fewer options sadly.
>

​One can certainly build N RtpSenders instead of 1 RtpSender, but there are
tradeoffs.  And you certainly still want only 1 RtpReceiver.  That's
probably a discussion worth having.​
​



>
> Maybe we can also discuss minimums.  I don't think that it's
> worthwhile having minimum values initially, and maybe not ever, though
> I'm open to the idea.  And I think that it's a universally applicable
> thing across all axes.  I can see cases for minimums on all three:
> frame rate (sign language), resolution (1x1, my image recognition
> can't deal), and quality (my eyes, ow, my eyes).
>

I tried many variations of different minimums, and mostly ended up thinking
it's too far down the slippery slope of complexity.  For all of the use
cases I could come up with, having minQuality was all I really needed.  The
rest seemed like they were adequately addressed by the bias/preference.


By this point, we have many separate discussions we could have:
- Simulcast (1 RtpSender vs N RtpSenders)  (The original proposal is for 1)
- Preference/Bias (3 dimensional vs. 1 dimensional)  (The original proposal
is for 1)
- Minimums: for all three dimensions, none, or some?  (The original
proposal is for 1, quality).