[FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

Jan Ekström jeebjp at gmail.com
Fri Oct 12 16:30:25 EEST 2018


On Thu, Oct 11, 2018 at 4:04 PM Jerome Martinez <jerome at mediaarea.net> wrote:
>
> In this case, the ratio (148 times the size of input) is proportional to
> the input frame size, and the test is on a fixed value (MAX_INT).
> I get now the reason to reserve more than the size of the input frame.
> I don't get the relationship between your explanation and these hard
> coded values (148 times the size of input and MAX_INT limit).
>
> Why 148x (37x4) and not 147 or 149?
> Why a warning and maxsize forced to MAX_INT if maxsize > MAX_INT? Is it
> an internal constraint of FFmpeg which would be not able to store
> encoded frames bigger than MAX_INT?
>
> Can any of that be changed e.g. warning only once for avoiding "spam" of
> such warning which hides other warnings during encoding?
>
> Jérôme
>

And while it seems like we're focusing on the arbitrary limit in
av_malloc (which is an issue of its own), I do note that for this
specific case this "worst case packed frame size" allocation heuristic
might have to be modified? Or at least explained if possible, so that
things can be improved in a proper way.

For historical context, this limit has been inside ffv1enc as follows,
number 1 being the current version:
1. avctx->width*avctx->height*37LL*4 ("added support for
AV_PIX_FMT_GBRP16" - ce2217b25eccda9f5c14022bd69792e71b417b73)
2. avctx->width*avctx->height*35LL*4 ("avcodec/ffv1enc: fix size used
for ff_alloc_packet2()" - 904a2864bdafe19d18db95ca54dfb36d72957a16)
3. avctx->width*avctx->height*((8*2+1+1)*4)/8 ("ffv1enc: switch to
encode2()." - 278d88689ba89c78f6c2667cf98025835567d78d)
4. ??? Limit was probably somewhere elsewhere or didn't exist before this

Best regards,
Jan


More information about the ffmpeg-devel mailing list