[FFmpeg-devel] [PATCH 17/57] avcodec/mpegvideo, mpegpicture: Add buffer pool

[James Almer]

On 4/30/2024 5:40 PM, Michael Niedermayer wrote:
> On Mon, Apr 29, 2024 at 11:13:58PM +0200, Andreas Rheinhardt wrote:
>> This avoids constant allocations+frees and will also allow
>> to simply switch to the RefStruct API, thereby avoiding
>> the overhead of the AVBuffer API.
>> It also simplifies the code, because it removes the "needs_realloc"
>> field: It was added in 435c0b87d28b48dc2e0360adc404a0e2d66d16a0,
>> before the introduction of the AVBuffer API: given that these buffers
>> may be used by different threads, they were not freed immediately
>> and instead were marked as being freed later by setting needs_realloc.
>>
>> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>
>> ---
>>   libavcodec/mpegpicture.c   | 155 ++++++++-----------------------------
>>   libavcodec/mpegpicture.h   |  27 ++++---
>>   libavcodec/mpegvideo.c     |  37 +++++++++
>>   libavcodec/mpegvideo.h     |   2 +
>>   libavcodec/mpegvideo_dec.c |  35 ++++-----
>>   libavcodec/mpegvideo_enc.c |  13 ++--
>>   6 files changed, 112 insertions(+), 157 deletions(-)
> 
> This seems to change the output of:
> 
> ./ffmpeg -y -bitexact -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -ps 50 -bf 1 -bitexact -an -qscale 5  -ss 40 -error_rate 4 -threads 1 /tmp/out4.avi && ./ffmpeg -y -bitexact -v -1 -loglevel 0 -i /tmp/out4.avi -bitexact -vsync drop -f framecrc -
> 
> --- A	2024-04-30 22:01:12.964146819 +0200
> +++ B	2024-04-30 22:00:57.407969834 +0200
> @@ -38,7 +38,7 @@
>   0,         32,         32,        1,   115200, 0x74c44bae
>   0,         33,         33,        1,   115200, 0x921c5255
>   0,         34,         34,        1,   115200, 0x9a8553a9
> -0,         35,         35,        1,   115200, 0x817b6334
> +0,         35,         35,        1,   115200, 0x310061fd
>   0,         36,         36,        1,   115200, 0x4c9a5f6d
>   0,         37,         37,        1,   115200, 0x5ee86279
>   0,         38,         38,        1,   115200, 0x04055061
> @@ -74,7 +74,7 @@
>   0,         68,         68,        1,   115200, 0x49dcbf4e
>   0,         69,         69,        1,   115200, 0x1ea1c7d1
>   0,         70,         70,        1,   115200, 0xdf77c67b
> -0,         71,         71,        1,   115200, 0x33d9d206
> +0,         71,         71,        1,   115200, 0x7f6bd16d
>   0,         72,         72,        1,   115200, 0x5e37cb3a
>   0,         73,         73,        1,   115200, 0x15abcda3
>   0,         74,         74,        1,   115200, 0xbf4dcbd4
> @@ -86,7 +86,7 @@
>   0,         80,         80,        1,   115200, 0x17d1d667
>   0,         81,         81,        1,   115200, 0x0c1fdf9c
>   0,         82,         82,        1,   115200, 0x7eabde6b
> -0,         83,         83,        1,   115200, 0x3bf6e873
> +0,         83,         83,        1,   115200, 0xe623e7af
>   0,         84,         84,        1,   115200, 0xf480dc82
>   0,         85,         85,        1,   115200, 0x5fd6e098
>   0,         86,         86,        1,   115200, 0xf520de95
> @@ -98,7 +98,7 @@
>   0,         92,         92,        1,   115200, 0x34cfe1c2
>   0,         93,         93,        1,   115200, 0x1d94e1c3
>   0,         94,         94,        1,   115200, 0x6d32e147
> -0,         95,         95,        1,   115200, 0x09fbefd0
> +0,         95,         95,        1,   115200, 0x7e40ee91
>   0,         96,         96,        1,   115200, 0xa5f5eb43
>   0,         97,         97,        1,   115200, 0x39b9ec3d
>   0,         98,         98,        1,   115200, 0x3256ec18

Last time a buffer pool change resulted in changed checksum for some 
frames it was because the decoder or encoder were touching uninitialized 
bytes, something made evident by the buffer coming from a pool (thus 
potentially being recycled).

Can you check if that's the case here? How different is the output?