[FFmpeg-devel] [PATCH] mxfdec: export aspect information.

[Tomas Härdin]

On Wed, 2012-09-19 at 07:11 +0200, Reimar Döffinger wrote:
> All other formats set width/height to the display size.
> For example for 1080p codec->height will be 1080, not 1088 even though that is the actual size.
> Problem with using DisplayHeight is that since we do not support cropping the top it will probably result in cropping some video data at the bottom while keeping the VBI lines...

DisplayHeight isn't what you think here. You're referring to
SampledHeight (I think). I've quoted S377m Annex E in the end of this
mail [1].

Let's take a look at the NOTE at the end of E.1.2. For say AVC-Intra 50
(16:9 1440x1080) it implies that StoredWidth/Height are 1440x1088,
SampledWidth/Height are 1440x1080 and DisplayWidth/Height are also
1440x1080. SAR = 16:9/1440:1080 = 4:3.

For say 4:3 IMX50 these dimensions could be 720x680, 720x608 and 704x576
with an offset of (8,32). SAR = 4:3/704:576 = 12:11.

Of course, the correctness of these values varies from file to file.
StoredWidth/Height is often the non-macroblock resolution (1440x1080)
and SampledWidth/Height are often omitted.

I've passed a bunch of files I have on disk through mxfdump in order to
try to demonstrate the mess you're getting yourself into :)
See [2]. Note that FrameLayout != 0 means some form of interlacing,
hency why the heights and Y offsets are halved.

> >>> (DisplayWidth/Height) if set. It's also possible for StoredWidth/Height
> >>> to be wrong (certain P2 files), in which case you must wait for the
> >>> dimensions to be probed before SAR is computed.
> >> 
> >> I very much don't think that broken files should be a significant
> >> concern, at least not when it is at the expense of correct files.
> > 
> > Yes, I'm actually leaning towards this too. I don't think it's illegal
> > for an MXF file to not specify these dimensions at all though, in which
> > case you'd have to probe anyway.
> > 
> > For now a simple solution to this that should at least not mess anything
> > up is:
> 
> I might look into this, if we agree on a view of what should be stored in width/height.

I think FATE needs a heavy dose of new samples at the very least. We can
probably ignore files that are completely bogus for now, like the one I
mentioned in the previous mail. IIRC it claimed to be 1280x720 instead
of 1920x1080 or something like that. Looking at the Identification pack
and applying specific hacks for such files may be a better solution.

/Tomas

[1]
E.1.2 Stored data and stored rectangle

The stored data comprises the entire data region corresponding to the stored rectangle for a single frame or field of the
image plus any start or end data bytes in the byte stream. The stored rectangle corresponds to a rectangle of stored
pixels described by the stored width and stored height properties. The stored rectangle byte count is defined by its width
and height dimension properties multiplied by the number of bytes per pixel.
The stored data may include bytes that are not derived from, and would not usually be translated back to, signal data.
This extra data is the start fill and end fill region. The sizes are defined by the image start offset and image end offset
properties.

The stored data may be aligned to a particular storage boundary, defined by the image alignment offset.

NOTE – In cases where compression systems are in use, the stored rectangle corresponds to the data which is passed to
the compressor and received from the decompressor. Since compression systems typically constrain the sizes of
macroblocks, the stored rectangle may be larger than the sampled rectangle and the display rectangle. Also, in these
cases, the definition of the macroblocks may dictate an offset from stored to sampled rectangle which is not equal in field
1 and field 2; this is described by the optional StoredF2Offset property below. In addition, when the stored rectangle
comprises merged fields, the sample rate property will be set to the frame rate according to E.2.1.

E.1.3 Sampled rectangle

The sampled rectangle is the rectangular region corresponding to the digital data pixels derived from an image source.
This includes the image and any auxiliary information actually sampled from the analog or digital source.
Although typically the sampled rectangle data is a subset of the stored data, it is possible that the sampled area may not
be a subset of the stored data. The sampled rectangle may overlap or encapsulate the stored rectangle.
The sampled rectangle is defined by its width and height properties in pixels. These properties default to the same value
as the stored width and height.

The mapping from the stored rectangle to the sampled rectangle is defined by the sampled X offset (SX) and sampled Y
(SY) offset properties, which give the zero-based coordinates of the sampled rectangle relative to the upper left corner of
the stored rectangle. These properties have a default value of 0. They may be positive or negative.

NOTE – The example in figure E.1 shows positive values for the SX and SY offsets.

E.1.4 Display rectangle

The display rectangle is the rectangular region which is actually visible in the signal raster.
The display rectangle directly maps to the SMPTE RP 187 production aperture. The display rectangle is defined by its
width and height properties in pixels. These properties default to the same value as the sampled width and sampled
height. Their values shall not be greater than the sampled width and sampled height.

The mapping from the sampled rectangle to the display rectangle is defined by the display X offset (DX) and display Y
offset (DY) properties, which give the zero-based coordinates of the display rectangle relative to the upper left corner of
the sampled rectangle. These properties have a default value of 0. Their values shall not be negative.


[2]
A nice 1280x720 file with square pixels (from Canon XF305):
    FrameLayout = 0
    AspectRatio = 16/9
    StoredWidth = 1280
    StoredHeight = 720
    StoredF2Offset = 0
    SampledWidth = 1280
    SampledHeight = 720
    SampledXOffset = 0
    SampledYOffset = 0
    DisplayHeight = 720
    DisplayWidth = 1280
    DisplayXOffset = 0
    DisplayYOffset = 0
    DisplayF2Offset = 0

A file where the container claims the essence is 1920x1088 even though it's 1920x1080 (from Canon XF305):
    FrameLayout = 0
    AspectRatio = 16/9
    StoredWidth = 1920
    StoredHeight = 1088
    StoredF2Offset = 0
    SampledWidth = 1920
    SampledHeight = 1088
    SampledXOffset = 0
    SampledYOffset = 0
    DisplayHeight = 1080
    DisplayWidth = 1920
    DisplayXOffset = 0
    DisplayYOffset = 0
    DisplayF2Offset = 0

Interlaced 1920x1080 (from OpenCube MXFTk Advanced):
    FrameLayout = 1
    AspectRatio = 16/9
    StoredWidth = 1920
    StoredHeight = 544
    SampledWidth = 1920
    SampledHeight = 540
    SampledXOffset = 0
    SampledYOffset = 0
    DisplayWidth = 1920
    DisplayHeight = 540

A 16:9 IMX30 (from BBC Research Avid MXF Writer):
    FrameLayout = 1
    AspectRatio = 16/9
    StoredHeight = 304
    StoredWidth = 720
    SampledHeight = 304
    SampledWidth = 720
    SampledYOffset = 0
    SampledXOffset = 0
    DisplayHeight = 288
    DisplayWidth = 720
    DisplayYOffset = 32
    DisplayXOffset = 0

A 4:3 IMX30 (from BBC Research Avid MXF Writer):
    FrameLayout = 1
    AspectRatio = 4/3
    StoredHeight = 304
    StoredWidth = 720
    SampledHeight = 304
    SampledWidth = 720
    SampledYOffset = 0
    SampledXOffset = 0
    DisplayHeight = 288
    DisplayWidth = 720
    DisplayYOffset = 8
    DisplayXOffset = 0