Re: maxHeight and maxWidth

On Sat, Feb 13, 2016 at 5:00 PM, Adam Roach <adam@nostrum.com> wrote:

> On 2/12/16 9:38 PM, Bernard Aboba wrote:
>
> On Feb 12, 2016, at 19:21, Adam Roach <abr@mozilla.com> <abr@mozilla.com> wrote:
>
> The clone/constrain/send solution has the same flaws in this case as it does in the general case. We already rejected that approach.
>
> [BA] The major flaw of cloning is the potential for simulcast streams to converge.  That flaw was addressed in RTCRtpEncodingParameters by introducing resolutionScaleDownBy - to ensure the streams remain distinct.
>
>
> Is that what you were saying in Seattle? I couldn't completely follow it,
> and neither could the minute taker -- but that's not what it sounded like.
> Here's what's reflected in the minutes:
>
>
> Cullen: if they come with different constraintsm they would have to be
> different payload type; not so for the bitrate
> ... having to have the JavaScript adjust the bitrate over time will
> interfer with congestion control; doesn't seem good
>
> Martin: the problem with this option is that we don't have a clear signal
> from the browser side to properly optimize this
>
> ...
>
> Ekr: is the only problem with C that the browser can't be smart about it?
> ... its major advantage is that it doesn't require any new SDP
> ... could we reuse that SDP with the other proposals?
>
> Bernard: there is a gotcha there
> ... @@@
>
> Peter: we could go to an option D where you clone tracks and then frob
> the framerate scale
>
> Justin: option C is not compatible with scalable coding, so it's a
> non-starter for me
>
> Cullen: agree
>
>
> So what I'm seeing it that the poor man's "clone and send" has a number of
> issues in general, including:
>
>
>    1. A increase in PT usage
>    ​
>
> ​Two RtpSenders can have the same set of codecs, with the same PTs.  So
this seems like a non-issue to me.​
 ​

>
>    1. Bad interaction with congestion control
>
> ​Shouldn't the general case of two RtpSenders (say, with two cameras)
handle congestion control fine?  If not, we have bigger problems.  If so,
then this seems like a non-issue​.  Besides, one of them is going to be 90
pixels tall.  There isn't a lot of bandwidth being used in that stream.


>    1. Suboptimal browser performance, and
>
> ​One of the RtpSenders is encoding 90 pixels high, so encoding time isn't
going to be much.  So this seems like a non-issue to me.

>
>    1. incompatibility with scalable coding.
>
> ​One of the RtpSenders​ is encoding 90 pixels high, so I don't think
scalability would gain you much anyway.

​ ​
So this seems like a non-issue to me.

>
>    1. Plus "@@@" above, which I *don't* think was "we might accidentally
>    have two identical streams" (which... would cause... what? All life as you
>    know it stopping instantaneously and every molecule in your body exploding
>    at the speed of light? I don't think the harm of converging the streams has
>    ever been clearly explained).
>
> ​I don't quite understand what your saying, but it sounds like you're
saying you don't think this is an issue.

I think we're out of issues.  Besides, as I keep saying, maxHeight doesn't
solve the "can only receive 90 pixels" use cases.  You have to clone
tracks, unless you are proposing we have *both* maxHeight *and* minHeight.​

>
>
>
> /a
>