W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2016

Re: maxHeight and maxWidth

From: Adam Roach <adam@nostrum.com>
Date: Sat, 13 Feb 2016 19:00:11 -0600
To: Bernard Aboba <Bernard.Aboba@microsoft.com>, Adam Roach <abr@mozilla.com>
Cc: Peter Thatcher <pthatcher@google.com>, Randell Jesup <randell-ietf@jesup.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <56BFD19B.2010100@nostrum.com>
On 2/12/16 9:38 PM, Bernard Aboba wrote:
> On Feb 12, 2016, at 19:21, Adam Roach <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
 2. Bad interaction with congestion control
 3. Suboptimal browser performance, and
 4. incompatibility with scalable coding.
 5. 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).

Received on Sunday, 14 February 2016 01:01:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:13 UTC