Måns Rullgård skrev 2011-08-22 18:05:
Tomas Härdin<tomas.har...@codemill.se> writes:
Måns Rullgård skrev 2011-08-22 16:04:
Luca Barbato<lu_z...@gentoo.org> writes:
On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
then we have a documentation hole, which field contains the correct values?
Both are correct but for different things. coded_{width,height} are the
actual pixel dimensions of the image including padding to a macroblock
multiple (or other padding). Plain width/height is the display size to
be cropped from the full coded image. This is how it always has been.
Anything using those values differently is broken and should be fixed.
In some cases the container may specify additional cropping which I'm
not sure where it's supposed to be reported.
Just to pre-empt anyone thinking of doing this any other way:
I suggest putting such information in AVFormatContext as four
AVRationals (width, height, xoffset, yoffset) so mov and mxf files can
be remuxed more accurately.
Non-integer dimensions?
Indeed. I've run across more than one such mov sample at work. I'm not
sure why one would want them, but remuxing shouldn't result in such
information being thrown out.
A minor alteration: It could also be carried as metadata I suppose,
instead of cluttering up AVFormatContext.
One common use case is for hiding VBI lines in IMX50 material.
/Tomas
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
