[FFmpeg-devel] [PATCH] nvenc: Compensate for hardware trying to mess with aspect ratio of DVD content.

tim nicholson nichot20 at yahoo.com
Mon Jan 19 16:16:01 CET 2015

Hash: SHA256

On 17/01/15 23:52, Nicolas George wrote:
> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>>> There is a very simple way of flagging content that is supposed to comply
>>> with BT601: the SAR is 512/351. If SAR is 64/45, that means someone before
>>> nvenc decided that the video is not expected to conform with BT601, and
>>> nvenc has no right to decide otherwise.
>> You fail to realise this but SARs are not necessarily arithmetic for
>> historical reasons.
> Care to explain how historical reasons can change the laws of geometry?
> If a visible surface with a physical aspect ratio of 16/9 is cut into
> 702×576 identical rectangular pixels, then the aspect ratio of each pixel is
> (16/9) / (702/576) = 512/351. Can you give one good reason for FFmpeg to
> use, internally, any other value?

I am struggling to follow some of the arguments, which seem far to
heated to be as useful as they could be.

However, as I understand the issue, whilst the above maths sound fine,
the visible surface mentioned above is framed within an actual surface
of 720x576 pixels which includes the 'digital overscan'

Taking the Sample/pixel aspect ratio (SAR) calculated above and feeding
that back into calculating a display aspect ratio *for the whole frame*
leads to a value that is not 16:9 (or 4:3), and it appears to be this
figure which is then reported as the DAR, rather than that of the active
picture. This is I think the disjoint between DAR and SAR that Kieran
refers to, there is only a mathematical relationship if you include the

It would appear that in some cases the SAR is calculated back from a
specified DAR of 16/9 being applied as the aspect ratio of the whole
frame and this seems to be the usual cause of issues (Adobe had to admit
they had got it wrong for years as they had assumed that 720x576 was 4/3
aspect ratio).

I am not sure what is currently wrong, and where, but please let us not
'fix' one scenario with a dirty hack that breaks hoers.

> Regards,

- -- 
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
Version: GnuPG v2


More information about the ffmpeg-devel mailing list