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
