Re: maxHeight and maxWidth

On 2/12/16 14:36, Peter Thatcher wrote:
> We've discussed the downsides of maxHeight/maxWidth in many f2f 
> meetings, so we can just go dig up the notes from before.

The only arguments I recall being raised is "we don't need them, so why 
specify them?" But now we have implementors coming to us saying they 
*do* need them, so that rationale kind of crumbles.

> But I recall the case against maxHeight and maxWidth is the complexity 
> and ambiguity that it introduces, as well as the duplication of 
> control.  You can already control the height and width of the track 
> via constraints on the track.

I don't think that argues one way or another: pretty much everything we 
can do on the senders/tranceivers can be done on the individual streams. 
The whole point of sender/tranceiver controls is to modify what goes on 
the wire as compared to the properties of the stream.

In terms of complexity, I'd love to hear you expand on your concerns 
here. Perhaps I'm being naïve, but once you implement the ability to 
handle scaleResolutionDownBy, you simply need to add excruciatingly 
simple logic on a per-frame basis along the lines of:

if (stream.current_resolution != stream.previous_resolution) {
   resizeScale =  scaleResolutionDownBy;
   if (stream.width / resizeScale > maxWidth) {
     resizeScale = stream.width / maxWidth;
   }
   if (stream.height / resizeScale > maxHeight) {
     resizeScale = stream.height / maxHeight;
   }
}

>   And if we did add a maxHeight and the frame is too big, it's not 
> clear what should happen: scaling, cropping, pillar boxes, etc.

Oh, that's easy. Unless we want to make the interactions unnecessarily 
complex, it needs to be the same thing as we get for 
scaleResolutionDownBy: scaling.


-- 
Adam Roach
Principal Platform Engineer
Office of the CTO