Tomas Härdin <tomas.har...@codemill.se> writes:
> 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.
What does a non-integer size even mean? It makes no sense at all.
--
Måns Rullgård
m...@mansr.com
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
