[FFmpeg-devel] [PATCH 2/2] avcodec/utils: Pretty print analog overscan style display aspect ratios

Michael Niedermayer michaelni at gmx.at
Sun Jan 18 20:12:14 CET 2015

On Sun, Jan 18, 2015 at 03:50:11PM +0000, Kieran Kunhya wrote:
> > the active area is stored in mpeg1/2 and should be used, its in the
> > pan scan variables IIRC, that way there is a very close to correct
> > mathematical relation between SAR, DAR and the active area in the
> > BT601 case
> > There should be no problem here with complying to BT601 and the
> > video coding specs
> Close isn't good enough. It has to be right.

yes, i think i understand now what you are talking about

let me try to summarize after reading some of these specs

NTSC does not seem to specify the active area exactly, or i fail to
find it in the specification

BT470 does though and being more recent i assume that can be used
it specifies the
Nominal line period (µs) 63.5555
and the Line-blanking interval (µs) as (10.9 ± 0.2)
for NTSC-M
this leaves an active area of 52.6555 ± 0.2 micro seconds

at a 13.5 Mhz sampling rate that is 710.8492 ± 2.7 pixel
as the active area

and 486 or 485 lines of that apparently
if we assume a SAR 10:11 as specified for 4:3 DAR in H264
that results with 486 lines in 712.8 pixels which is within
710.8492 ± 2.7 pixels and thus correct
or with 485 lines in 711.3333 which is also within the tolerance,
actually just half a pixel off

It appears though the archive.org document ignores the tolerancies
and assumes the center of the interval rounded to the next integer
or multiple of 2 in case of lines is more correct

If someone feels the center is better for analog sources,
i wont disagree, but i dont think analog cameras had this level of
precission nor does it make sense to round these values if one tries
to hit the center with religious fanatism

also we do not live in the analog era anymore and the digital formats
all choose to pick a convenient point in the allowed tolerance
intervall that analog provided.

Its a bit like with other units, like the second which was defined
based on the period of the Earth's orbit around the Sun until atomic
clocks where available when it was redefined accordingly. of course
a second before and afterwards do not match entirely exactly

nor does the active area in integer pixels of digital video match
exactly the midpoint of what analog defined as intended it cant
as thats not an integer number of pixels at the sampling frequency
the world choose to use and this leads to these tiny differences
in the aspect ratio

If you think we can improve the precission of handling some material
aspect ratio wise or otherwise, lets do it!

But please lets work toward improving FFmpeg and not to troll each
other, thats just not moving anything forward

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150118/4cdde664/attachment.asc>

More information about the ffmpeg-devel mailing list