On Sun, Dec 11, 2016 at 7:48 PM, Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: > On 11.12.2016 10:04, Hendrik Leppkes wrote: >> On Sat, Dec 10, 2016 at 6:53 PM, Andreas Cadhalpun >> <andreas.cadhal...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
