[FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: Handle non-square pixel aspect ratios

Philip Langdale philipl at overt.org
Sat Jan 17 20:05:38 CET 2015

On Sat, 17 Jan 2015 19:14:04 +0100
Nicolas George <george at nsup.org> wrote:

> Le septidi 27 nivôse, an CCXXIII, Philip Langdale a écrit :
> The 45/44 value looks like 704/720: the sign that some people long
> time ago in committees in the broadcast industry could not agree
> whether the aspect ratio applies to the whole image or only the part
> that is displayed on screen.
> Considering it dates back to the time of CRT displays, which have
> knobs to distort the image by way more than 2%, my opinion about it
> is that it should be just ignored, people who care for that much
> precision can insert a setsar filter by hand. And if people really
> want to take it into account, the place is in demuxers or decoders,
> definitely not in encoders for modern codecs.
> It seems that some people at nvidia think differently, they think
> this old mistake should be renewed again and again.

You seem to be exactly right - if I feed in other resolutions with
the PAL DVD SAR/DAR values, it doesn't mangle them.
> Can you test what happens if you set darWidth/darHeight to 704/405,
> i.e. compensate the 45/44 factor added by nvidia with a 44/45 factor?
> (I am not sure you can do it with Timo's latest patch due do big
> denominators.)

Yep, that produces correctly compensated results.

> It would also be interesting to know what exact conditions trigger the
> misfeature: is it the width being 720? Tabulating the space of
> parameters could help see a little clearer.

I did a few quick checks and it looks very specific: 720x480 and
720x576 are mangled 45/44 but any other resolution (even 720 width) is
left untouched.

> And of course, opening a ticket if there is a bug tracker somewhere
> (and if it is not a placebo like google's).

I hope Agatha is reading all these emails. I'm not aware of any formal
tracker I can submit to. :-/

I know you say it should be the decoder's responsibility, but given the
very specific nature of what's happening here, might it be worth
compensating in the encoder? Otherwise it's very very confusing, as you
can see from my struggles.


More information about the ffmpeg-devel mailing list