[FFmpeg-devel] [PATCH] opt: check image size when setting it

Hendrik Leppkes h.leppkes at gmail.com
Sun Dec 11 22:03:42 EET 2016


On Sun, Dec 11, 2016 at 7:48 PM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> wrote:
> On 11.12.2016 10:04, Hendrik Leppkes wrote:
>> On Sat, Dec 10, 2016 at 6:53 PM, Andreas Cadhalpun
>> <andreas.cadhalpun at googlemail.com> wrote:
>>> On 10.12.2016 18:40, Hendrik Leppkes wrote:
>>>> and just adds extra burden when these limits are
>>>> changed/improved (say by making them pixfmt aware as discussed in
>>>> another thread, which this function could never know).
>>>
>>> There is no extra burden, because av_image_check_size would have to
>>> be changed in that case anyway to accept the largest value valid
>>> for any pixel format.
>>>
>>
>> av_image_check_size2 was introduced by Michael now which works in the
>> context of a pix_fmt, which for many formats allows significantly
>> larger images then the old function (up to factor 4 larger)
>
> Actually there is a factor of 64 between AV_PIX_FMT_MONOWHITE and
> AV_PIX_FMT_AYUV64LE, the latter of which amounts to the old limit.
>
>> I still see the problem that this option code does not know which
>> pix_fmt the numbers relate to and as such would keep the old limit in
>> place despite there being no technical reasons for it.
>
> And I still think that av_image_check_size should be changed to
> accept the largest value valid for any pixel format (once every place
> needing stricter limits is switched to the pixel format sensitive
> check).
> Do you disagree with this or what is your point?

I could probably live with a simple w*h overflow check (more or less),
which av_image_check_size then probably would end up being if I
understand you right?
Thats much higher then the current limit in most cases and while we
should try to move this to size_t/ptrdiff_t eventually to lift the
limit even higher on 64-bit platforms, its OK for now.

- Hendrik


More information about the ffmpeg-devel mailing list