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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
