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

[Marton Balint]

On Mon, 26 Sep 2016, Jan Ekstrom wrote:

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

Thanks, I think it is 2) indeed. Also container width/height information 
is overridden from what is probed in the codec, so even if you set 
height to 576 in the demuxer part, later, when the first frame is 
analyzed, it will get written back to 608.

You might also check some earlier mails in a similar topic: 
http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/131203.html

Regards,
Marton