[FFmpeg-devel] [PATCH] mov: support for Quicktime CLEF/TAPT atoms

Michael Niedermayer michaelni at gmx.at
Tue Jul 3 16:04:32 CEST 2012

On Tue, Jul 03, 2012 at 08:35:20AM +0100, Tim Nicholson wrote:
> On 02/07/12 19:38, Michael Niedermayer wrote:
> > Hi
> > 
> > 
> > On Thu, Jun 28, 2012 at 10:35:23AM +0200, Bram Senders wrote:
> >> Hi,
> >>
> >> FFmpeg does not currently support the Quicktime CLEF (Track Clean
> >> Aperture Dimensions) and TAPT (Track Aperture Mode Dimensions) atoms.
> >> (See https://developer.apple.com/library/mac/#documentation/QuickTime/QTFF/QTFFChap2/qtff2.html)
> >> These atoms are necessary for detecting the correct dimensions for
> >> some videos, since they take precedence in Quicktime over the normal
> >> TKHD (track header) width/height and over the track PASP (pixel aspect
> >> ratio).
> >>
> >> The attached patch adds support for these atoms. Sample videos can be
> >> found at https://ffmpeg.org/trac/ffmpeg/ticket/1485.
> > 
> > This patch worsens the aspect ratio of the sample from:
> > https://ffmpeg.org/trac/ffmpeg/ticket/1439
> > 
> > the center circle looks more round before this patch than afterwards
> >
> I am in favour of the idea of supporting these Quicktime atoms,
> *however* I am concerned at how they may be interpreted within ffmpeg.
> Quicktime player generally gets things right, software
> decoders/transcoders etc generally ignore them. The above patch seems to
> blend them together unless I am mistaken.
> For example a standard 720x576 Tv SD "widescreen" image is generally
> referred to as being 16:9. However to assume (as most software utilities
> do)* that this means that the pixel aspect ratio should be calculated on
> the basis of the full 720 pixels width being in the ratio of 16/9 times
> the 576 pixel height would be incorrect.
> This is because it is the "active" area of the picture (702x576) that is
> in the ratio of 16:9. This "active" area corresponding to the original
> analogue TV active picture area. When the digital standard was invented
> margins were provided to allow corrections for mistimed material without
> introducing extra "blanking" down one side or other of the picture. The
> standard BBC testcard W is full width, but with markers indicating the
> active picture limits.
> Most software, when converting the above image to a square pixel
> display, will use 1024x576. Qicktime player however (if the atoms are
> set correctly) will either display the 702x576 active area as 1024x576,
> or the whole image as 1049x576, either ensures circles are circular. An
> export from FCP will set these atoms correctly.
> This issue only occurs in SD TV. HD TV thankfully defines a square pixel
> full frame 1920x1080 as 16:19, and computer sequences do not have an
> analogue history to be compatible with.
> Now whilst only displaying the active picture content might be
> appropriate, for any manipulation of that content, such as transcoding,
> resizing, etc the whole frame should be dealt with, which brings us back
> to how ffmpeg should handle such atoms.
> I note that a recent MXF patch from someone in BBC R&D was rejected
> because it introduced a similar disjoint between the pixel (sample)
> aspect ratio, the display aspect ratio and the frame resolution. A
> concept that ffmpeg does not currently recognise as it assumes:-

> I therefore suspect that for ffmpeg to handle these properties correctly
> (given that they deal principally with how the image should be viewed)
> requires some fundamental reworking to allow the assumed relationship
> between ratios mentioned above to be broken.

ffmpeg supports this since many years, in mpeg2video for example.
it works like this: you have a SAR and only a SAR. theres no concept
of DAR in the API. The display aspect ratio is only defined through
SAR and the pixel rectangle for which it is calculated.

the DAR of a video depends on which area is choosen to be the area
for the DAR as well as the SAR of the video

I dont think anything needs to be changed in the API for this patch,
its just needed to set the SAR correctly. It can only have 1 correct
value. That is independant of the rectangle choosen for viewing

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120703/a4466b97/attachment.asc>

More information about the ffmpeg-devel mailing list