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

[Jerome Martinez]

On 12/10/2018 15:30, Jan Ekström 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.

Jérôme