On Mon, 26 Sep 2016, Jan Ekstrom wrote:

On Sep 26, 2016 04:05, "Marton Balint" <c...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to