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

For min, you can shut off the stream where there aren't enough bits, but
what should you do when the stream goes over the application-defined max?

I am very open to having the app do much of this stuff dynamically, since
it means the static configuration controls can be simpler, but I'm not sure
we can toss maxBitrate/maxQuality.


On Wed, Feb 19, 2014 at 8:32 PM, Chris Wendt <chris-w3c@chriswendt.net>wrote:

>
> Maybe I’m reading more into this or maybe I’m making it more complex than
> necessary, or maybe i’m stating the obvious, but I think this makes sense.
>
> My originally assumed premise was that you setup a stream with a set of
> parameters and let the implementation map those parameters to video encoder
> rate controls and it runs happily along independently doing adaptive
> bitrate things within the context of the given parameters.
>
> Taking things to the next level, we can imagine having and likely
> requiring application level control, particularly for SVC and simulcast or
> in cases where you have multiple RTPSenders, where we need to control
> across multiple potentially unrelated and independent media streams and
> based on some metrics feedback that, for example, quality is suffering
> given some bitrate constraints, so I should switch to half resolution, or
> no longer send the 3rd enhancement layer or reduce the number of RTPSenders.
>
> So what would be the feedback mechanism here?  Is this up to the
> application developer to monitor metrics themselves if even possible or
> practical?
>
> I would propose we think about providing callback hooks based on things
> like min/max bitrate and min/max quality thresholds.  And maybe
> specifically define the basic set.
>
> Again, I think the current discussion around the simple set of parameters
> satisfies the static config case, but when we talk about max or min type of
> parameters, I think there needs to be some feedback to notify that
> application when the min/max point is reached so it can act appropriately.
>
> Thoughts?
>
>
>
> On Feb 19, 2014, at 6: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.
> >
> > 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).
>
>
>