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

[Tim Nicholson]

On 03/07/12 15:04, Michael Niedermayer wrote:
> 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.
>>
>> [...]
>> 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.
> 
> 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.
> 

This sounds like the right approach. However where can you currently
define the pixel rectangle for which the DAR is calculated? For example
the setdar filter allows the DAR to be set and calculates the SAR on the
basis of the equation I quoted.

My comments were based upon the above equation and the statement made in
response to the mxf issue by Baptiste "...The problem is that setting
sample aspect ratio to these values will break the rule width/height ==
dar/par which is expected in many places"


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

Quite

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


I agree SAR is the important figure, but it seems that "..in many
places..." it is derived from a provided DAR figure with no reference to
the relevant pixel rectangle.
>
-- 
Tim