W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2017

Re: Proposal: align video scaling with JSEP

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 5 Oct 2017 10:12:24 +0000
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
CC: WebRTC WG <public-webrtc@w3.org>
Message-ID: <HE1PR07MB09707A38E7E19B15D2FC2D62C9700@HE1PR07MB0970.eurprd07.prod.outlook.com>
On 02/10/17 18:44, Stefan Håkansson LK wrote:
> On 02/10/17 18:30, Cullen Jennings (fluffy) wrote:
>>> On Sep 26, 2017, at 5:56 AM, Stefan Håkansson LK
>>> <stefan.lk.hakansson@ericsson.com <mailto:stefan.lk.hakansson@ericsson.com>>
>>> wrote:
>>> Therefore I propose we remove the current text on 'centering, scaling,
>>> cropping', and instead reference JSEP section 3.6.2.
>> That is what we originally had and Martin and others complained that more advice
>> was needed. I don't think we can change the current advice but it still seems we
>> need to say something to have consistent behaviour between browsers. I do think
>> consistent behaviour is important because removing this going to result in
>> letter boxing and when one thing does it one way and something else does it
>> another, you can end up with the situation with a black border all the way
>> around the outside of image. Apps will need to know what the browser are going
>> to do so that the application can compensate to achieve the desired outcome for
>> the application.
>> I think EKR and Justin have argued for one of the principals being don't loose
>> information by cropping as this is really bad in cases like screen share. They
>> are also arguing for don't change aspect ration (other than minor bit caused by
>> rounding error in scaling ).  So I think that means this needs to say something
>> along the lines of black border is added to image to get to correct aspect
>> ratio, then it is scaled to get to correct size.
> Part of my reasoning is that the sender side does not (usually) know the
> rendering size on the remote end. All the sender knows is what the
> receiver is able to receive/decode, it does not know the rendering
> dimensions so it would be impossible to know if there would be a black
> border anywhere when this is eventually rendered. "Correct" size is
> unknown as I have understood it.

I added a note trying to explain that letterheading/pillarheading is the 
result if the track aspec ratio is different from the video element 
aspect ratio (regardless of whether video has been rescaled or not): 
Received on Thursday, 5 October 2017 10:12:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:52 UTC