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

Paul B Mahol onemda at gmail.com
Fri Oct 12 17:36:28 EEST 2018


On 10/12/18, Jerome Martinez <jerome at mediaarea.net> wrote:
> On 12/10/2018 15:30, Jan Ekstroem wrote:
>> 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.
>
>
> Thank you for the feedback.
> I was focused on ff_alloc_packet2() which accepts 64-bit integers, and I
> did not check what is behind (limited to INT_MAX too).
> I understand now that this is a global limit, not tied to FFV1 encoder
> (but when this limit is removed from mem.h, there will be a review of
> ode which test this limit before calling ff_alloc_packet2()...).
>
> As you said in the other answer, it was unrealistic to hit such limit in
> 2005, but now... 2 GB by packet is still huge (the input frame is "only"
> 128 MB), but the multiplier used in FFV1 encoder makes the limit hit for
> "basic" 4K frames. 8K frames are approaching...
> A bit complex for me to remove this 2 GB  limit for sure everywhere :(,
> so I try to find another solution.
>
>
>>
>> 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
>
> I see it but still don't catch the reason (and I am very curious to find
> an input frame able to e.g. make an output  frame 2x bigger than the
> input frame).
> Eager to have some background about it (Michael?).
>
> I guess there is a good reason for the "37LL*4" which is huge (note: I
> am afraid I did not update this limit when I implemented
> AV_PIX_FMT_GBRAP16, which is 4/3x bigger), so now trying to find a way
> to warn the user but not with 1 message per frame.
>
> If I can not (easily) remove this limitation, would limiting the message
> to 1 iteration for a whole stream be an acceptable patch?
> If so I'll send such patch.

I'm looking in adoption of v4 (and improve it) version sooner than never.

Ignoring issue all together may cause crash for specially crafted
input files, even
when such scenario is highly unlikely.

The limit of 2GB or whatever small value should ultimately be removed
at some point.


More information about the ffmpeg-devel mailing list