[FFmpeg-devel] [PATCH 17/57] avcodec/mpegvideo, mpegpicture: Add buffer pool
Andreas Rheinhardt
andreas.rheinhardt at outlook.com
Wed May 1 00:07:37 EEST 2024
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?
The buffer here is initially zeroed, so valgrind will never show any
uninitialized reads.
- Andreas
More information about the ffmpeg-devel
mailing list