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.

Best regards,
Jan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to