[FFmpeg-devel] [PATCH 31/39] avcodec/encode: Always use intermediate buffer in ff_alloc_packet2()

[James Almer]

On 5/22/2021 5:24 PM, Michael Niedermayer wrote:
> On Fri, May 21, 2021 at 11:17:34AM +0200, Andreas Rheinhardt wrote:
>> Up until now, ff_alloc_packet2() has a min_size parameter:
>> It is supposed to be a lower bound on the final size of the packet
>> to allocate. If it is not too far from the upper bound (namely,
>> if it is at least half the upper bound), then ff_alloc_packet2()
>> already allocates the final, already refcounted packet; if it is
>> not, then the packet is not refcounted and its data only points to
>> a buffer owned by the AVCodecContext (in this case, the packet will
>> be made refcounted in encode_simple_internal() in libavcodec/encode.c).
>> The goal of this was to avoid data copies and intermediate buffers
>> if one has a precise lower bound.
>>
>> Yet those encoders for which precise lower bounds exist have recently
>> been switched to ff_get_encode_buffer() (which automatically allocates
>> final buffers), leaving only two encoders to actually set the min_size
>> to something else than zero (namely aliaspixenc and hapenc). Both of
>> these encoders use a very low lower bound that is not helpful in any
>> nontrivial case.
>>
>> This commit therefore removes the min_size parameter as well as the
>> codepath in ff_alloc_packet2() for the allocation of final buffers.
>> Furthermore, the function has been renamed to ff_alloc_packet() and
>> moved to encode.h alongside ff_get_encode_buffer().
> 
> breaks:
> 
> ./ffmpeg -f lavfi -i testsrc=size=5632x3168 -pix_fmt yuv420p -vframes 1 -bitexact  -vcodec ffv1   -y ffv-bigrgb-tocket6005.avi
> 
> [ffv1 @ 0x559df8384f40] Cannot allocate worst case packet size, the encoding could fail
> [ffv1 @ 0x559df8384f40] Failed to allocate packet of size 2147483551
> Video encoding failed
> Conversion failed!

av_fast_padded_malloc() and av_fast_malloc() are trying to allocate more 
memory than allowed and ultimately required. They need to be adapted so 
they behave the same as av_fast_realloc().

I have a patch for that, will send it later.