On Thu, Oct 11, 2018 at 4:04 PM Jerome Martinez <jer...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel