[FFmpeg-devel] [PATCH 2/2] lavf/mxfdec: begin utilizing the newly parsed widths and heights

Jan Ekstrom jeebjp at gmail.com
Mon Sep 26 20:29:43 EEST 2016

On Sep 26, 2016 04:05, "Marton Balint" <cus at passwd.hu> wrote:
> Overriding width/height with display width/height does not seem right, check what happens with a PAL IMX50 MXF file for example. If you want to signal this, then a stream side data with some AVPanScan values might make more sense.

Such a file was actually the reason why I started looking into this :)
. And it would all depend on the definition of width/height in
codecpar, which as far as I can tell is not clearly cut (see the notes
regarding container crop in at least the AVC decoder, I think?). My
understanding was that it would be the displayed width/height. Of
course, the container cropping/padding makes this less simple, since
you have:

1) Decoded picture
2) Decoder cropped picture (what the decoders *currently* output)
3) Decoder cropped picture cropped/padded according to available metadata

So my understanding was - since a decoder should output the pictures
according to 3) - that the displayed width/height fields should be
utilized for signaling the final display width/height of the picture.
The X/Y offset handling of course should have had its own fields
*somewhere* so that stuff could be done in some common part of avcodec
(for example). But if the codecpar->width/height is specified to 2)
(at least in lavf), then of course side data would be the correct way
to handle this. Also thanks for the hint regarding AVPanScan, I had no
idea this existed. Will have to check if it actually is used anywhere.

Best regards,

More information about the ffmpeg-devel mailing list