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

[Tim Nicholson]

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:-

DAR = HORIZONTAL_RESOLUTION / VERTICAL_RESOLUTION * SAR

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.


*Adobe failed to take account of this issue until around CS4/5 when they
finally realised they had got it wrong and fixed it under pressure from
broadcasters at a time they were trying to get into that market.

Sorry, rather a long 2 cents/pennies etc worth. But I think we need to
be clear about the issues.

-- 
Tim