From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E04924A484 for ; Tue, 30 Apr 2024 20:58:17 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4CD9168D62B; Tue, 30 Apr 2024 23:58:15 +0300 (EEST) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 72FAA68D4EF for ; Tue, 30 Apr 2024 23:58:08 +0300 (EEST) Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-5d8b519e438so4805674a12.1 for ; Tue, 30 Apr 2024 13:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714510686; x=1715115486; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=1DVjJ9eBAb22gIyYv0uNv0l0kY+2wJiKKbRZpTDiNr8=; b=F05IJH8nlnlsag0oi6lsTL6p0nofRh9gqEc6o2xGj8wyaihvPxUl0YjPU5psB7EC8g G+PW4Lk2kqPMtEBESabafbNazKFzlw0y7Js3t2fJ3XklMlKcIcbP+CBu53gXn2lUTx99 wiUYgTihMdSLIiBCy8Xh0nrWscZpkhnDH+uIDa81veGVnuGkKcVAItVBobhKdL9TEmHF TPzPvRKiMllFYvKXYIqXfAjJ89hqWZ06jU8CpXzWxq+VRg7M9Z9gzrbEQj869TpQ4Esu 85qOEWYYUfX31Qv0nHGfYu3pNZfZ8pb7DcRehgISWVdQ6IGO/saPyOHOnNpD77UADqUi zTvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714510686; x=1715115486; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1DVjJ9eBAb22gIyYv0uNv0l0kY+2wJiKKbRZpTDiNr8=; b=v82xwu6hUFCgRs+KWgtrtzDMbm4x7h3Qy8uJs4Wj94h5zSeDM7NQaZkDhDS3o/tkE7 ZU50HlFpYYy8XHSdi09E3BlDMF3cEJwXu7mB6X98QMKo2g8R3eyDfg2PeHxdrT8dA5fa OxUh+v9nfeftwS4cmSuXMa1UDEGCs3qUk7TVK5FQO8Ia+GtOcfV/c5hSqrYONELtRzSL zmSeowpaQTjfxTCOB3awU02AGgKY2ny2JzUH9lOQXtOzu0M5x2v+/lvYXAl1mKRSU5Bn jDtaB0pccBDNh80ipPp9BVxvJfI6vncUa9IP+NEVbCG2/VYi0E1y004yUyFiFyHo+qEM cfZg== X-Gm-Message-State: AOJu0YwxEp3LHP/RDSzb/EYTs0VWNgor/WUPsLFy4PkyN7wTH1XVaHg1 dw4Dg9ZcZrtw13tnOh/W0aJ7/USyqJQ/TimeSelq9MAWiAnVG44zD9Ap3w== X-Google-Smtp-Source: AGHT+IEz0MK2lYlqNrzIvMRPHfOhcuur3jRonvyi4JxdGf6jedGm50k/HJqXCGSFKilGmgFFQCtO2A== X-Received: by 2002:a17:90a:e7c2:b0:2b1:ae20:91b6 with SMTP id kb2-20020a17090ae7c200b002b1ae2091b6mr664041pjb.8.1714510686159; Tue, 30 Apr 2024 13:58:06 -0700 (PDT) Received: from [192.168.0.10] ([190.194.167.233]) by smtp.gmail.com with ESMTPSA id nw10-20020a17090b254a00b002b0e8d4c426sm29867pjb.11.2024.04.30.13.58.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Apr 2024 13:58:05 -0700 (PDT) Message-ID: Date: Tue, 30 Apr 2024 17:58:03 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20240430204026.GS6420@pb2> Content-Language: en-US From: James Almer In-Reply-To: <20240430204026.GS6420@pb2> Subject: Re: [FFmpeg-devel] [PATCH 17/57] avcodec/mpegvideo, mpegpicture: Add buffer pool X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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 >> --- >> 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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".