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

Nicolas George george at nsup.org
Sat Jan 17 19:14:04 CET 2015

Le septidi 27 nivôse, an CCXXIII, Philip Langdale a écrit :
> On Fri, 16 Jan 2015 22:17:56 +0100
> Nicolas George <george at nsup.org> wrote:
> Ok. I did this test and it produces correct results - SAR 133:221 which
> yields the correct final aspect ratio,

This is a good start.

>					 but if I try and do a real world
> case, like my PAL DVD, it goes wrong - and Timo's patch goes wrong too,
> with this same weird 1.02 (45/44) scale factor.

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

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.

> So I feed in this input:
> Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 720x576
> [SAR 64:45 DAR 16:9], 25 tbr, 25 tbn, 25 tbc
> With libx264, I get the same SAR and DAR out.
> With nvenc, I get:
> sample_aspect_ratio=16:11
> display_aspect_ratio=20:11
> which is everything off by ~1.02.
> That's with Timo's patch and with hard-coding the darWidth and darHeight
> to 1024x576. Same result.

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.)

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.

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


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150117/c17dd257/attachment.asc>

More information about the ffmpeg-devel mailing list