From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id D86114D8BD for ; Wed, 3 Dec 2025 14:36:23 +0000 (UTC) Authentication-Results: ffbox; dkim=fail (body hash mismatch (got b'49daWDydvECamKTDqwBBUHsM663KDdNnN56RBickADY=', expected b'ycLwt6Kxuk1jY65x2stFJSE9cEX+1uG8bNZkDZ9H2qc=')) header.d=ffmpeg.org header.i=@ffmpeg.org header.a=rsa-sha256 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ffmpeg.org; i=@ffmpeg.org; q=dns/txt; s=mail; t=1764772571; h=mime-version : to : date : message-id : reply-to : subject : list-id : list-archive : list-archive : list-help : list-owner : list-post : list-subscribe : list-unsubscribe : from : cc : content-type : content-transfer-encoding : from; bh=49daWDydvECamKTDqwBBUHsM663KDdNnN56RBickADY=; b=QXiA5V6WDrUFI3HPba6ZfdSwSBArptG4cGdrDKUgA4FgWzCuyWii03c67NQgZSs2qSqjv oq214jSFuWPRs31V2gN3tbHtOntClSzBQX1we+G4qrfyxFpnfN7RwMCq3jFKhDlAWaf2+Ke hTzNotmbSALjTpU+zICpUcXb6zDCmGyDTpWO2IZ7o6NoQobKUKBWTDXbChmFLa6WkoWvVxQ EO7xGgxVzAaBDtIj1YKXj6FcDXJa4edlrR8TnQ2BC1jiDNfzhtt717a6cVsM72tPpGGfeGt 9wWBYS3icuqeaWKb/mvbPB69F3fV+5KZty553mppoMU6Adx7ErvdPhM/htDw== Received: from [172.19.0.3] (unknown [172.19.0.3]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 396B86904E7; Wed, 3 Dec 2025 16:36:11 +0200 (EET) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=ffmpeg.org; s=arc; t=1764772559; b=brrf+1BOaovHqEHcIACVWvFjZn07EogLJDa0xUpXy+oamF1PNcgcGE+lpgniUdX4VSQNE 79CEaO/77jHovKCCBRDxtoDAHRZFa+L2HpMVnN8MpxgN13A86GqVywJCHshjqQTsmm6NTb1 1ghYoViEcpRtXsRdS+fzMO/rsnckF4CdxyONOhRt+dAJtzBm+mEUdtYZ6Yi7//4j1rJ2sSQ YLyfuuzRoh9mch4NztIP4/caUrfj0f2uKqy8JGCu4A//kvt7ulDKfAaL5q7u8LkoDvvdLRO CawwABelGcin1PCmca7skcDCEmDNU5qcfwOpxO19FW62hwbbjoVqrg1cZDGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=ffmpeg.org; s=arc; t=1764772559; h=from : sender : reply-to : subject : date : message-id : to : cc : mime-version : content-type : content-transfer-encoding : content-id : content-description : resent-date : resent-from : resent-sender : resent-to : resent-cc : resent-message-id : in-reply-to : references : list-id : list-help : list-unsubscribe : list-subscribe : list-post : list-owner : list-archive; bh=u/T9aGBv5PnIRF6Zkk9HZmoGezvFZkffAeexrXO1wfY=; b=ZNMGWUnm7+0l9tafO0G11zLbAHS7apUcaFIQ1/iyg4KPeRVbJb8OTCMggi69DX/eEemxo uVozPiKWWjmd8jf6JRtFQ/we5Dz+ozabmBcVFKXe4WuGkOLUi99xg3NEB0z6ttUHzWaQUT2 tderkzcZyUIdtfdVqxi+ThbhOsLVwYbMP9ZYzI95WrI2Hdzp1/6ag939Oc4mCSKOd4SooXY LRRHOsxwWGIpkTdRyWQoQFApIopL9GrMQEFANFPhThnPIlV3DKch/HYSOd/Kq/JR9km9tsQ mxg/Jk52tleIkaDFUBOCAPq2kxj3hSxEq2vmH4JWGdkYJcqoHiAHrKkwm6nA== ARC-Authentication-Results: i=1; ffmpeg.org; dkim=pass header.d=ffmpeg.org header.i=@ffmpeg.org; arc=none; dmarc=pass header.from=ffmpeg.org policy.dmarc=quarantine Authentication-Results: ffmpeg.org; dkim=pass header.d=ffmpeg.org header.i=@ffmpeg.org; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=ffmpeg.org policy.dmarc=quarantine DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ffmpeg.org; i=@ffmpeg.org; q=dns/txt; s=mail; t=1764772552; h=content-type : mime-version : content-transfer-encoding : from : to : reply-to : subject : date : from; bh=ycLwt6Kxuk1jY65x2stFJSE9cEX+1uG8bNZkDZ9H2qc=; b=JOWEn//A/P8PTDqimIFVWAPKRyyASCjVZFGh5nw1N/e5D6tRhrnWrKBkfXVTT4m5/LQA0 kbK5R5xB0mJyCg5JcqpkzGrSDihRSUlcJ/0gS1Pb29tGhOxj55aLc07KNmoill8W6QV3dXq +oJYcCy8iit2SmYwWvtdpdIKn833ovpc1gynXz7RemFrHAoFBnRmic7Rb23jybUBPZlf7fm /9q2r4OPaEWpzzh4TFj4UboWYEBGIPoUXGAilKhJcxjeldkq+Hc4d498V9NuodF1qw+Pm5E NZwteZ3Ybj5IjSGqPk2IT8uB8eHaAFi9CIafSYusgOm0BzE7wZTYenwCl5sA== Received: from 55ca25703178 (code.ffmpeg.org [188.245.149.3]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 3B8C169046B for ; Wed, 3 Dec 2025 16:35:52 +0200 (EET) MIME-Version: 1.0 To: ffmpeg-devel@ffmpeg.org Date: Wed, 03 Dec 2025 14:35:51 -0000 Message-ID: <176477255236.39.11997917057008005889@2cb04c0e5124> Message-ID-Hash: 6IPKQHEOHFYBQ4L7CGBDGYKWVYVOOVHG X-Message-ID-Hash: 6IPKQHEOHFYBQ4L7CGBDGYKWVYVOOVHG X-MailFrom: code@ffmpeg.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-ffmpeg-devel.ffmpeg.org-0; header-match-ffmpeg-devel.ffmpeg.org-1; header-match-ffmpeg-devel.ffmpeg.org-2; header-match-ffmpeg-devel.ffmpeg.org-3; emergency; member-moderation X-Mailman-Version: 3.3.10 Precedence: list Reply-To: FFmpeg development discussions and patches Subject: [FFmpeg-devel] [PATCH] avcodec/vp3: Sync VLCs once during init, fix crash (PR #21089) List-Id: FFmpeg development discussions and patches Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: mkver via ffmpeg-devel Cc: mkver Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Archived-At: List-Archive: List-Post: PR #21089 opened by mkver URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21089 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21089.patch 6c7a344b65cb7476d1575cb1504e3a53bcbc83e7 made the VLCs shared between threads and did so in a way that was designed to support stream reconfigurations, so that the structure containing the VLCs was synced in update_thread_context. The idea was that the currently active VLCs would just be passed along between threads. Yet this was broken by 5acbdd2264d3b90dc11369f9e031e762f260882e: Before this commit, submit_packet() was a no-op during flushing for VP3, as it is a no-delay decoder, so it won't produce any output during flushing. This meant that prev_thread in pthread_frame.c contained the last dst thread that update_thread_context() was called for (so that these VLCs could be passed along between threads). Yet after said commit, submit_packet was no longer a no-op during flushing and changed prev_thread in such a way that it did not need to contain any VLCs at all*. When flushing, prev_thread is used to pass the current state to the first worker thread which is the one that is used to restart decoding. It could therefore happen that the decoding thread did not contain the VLCs at all any more after decoding restarts after flushing leading to a crash (this scenario was never anticipated and must not happen at all). There is a simple, easily backportable fix given that we do not support stream reconfigurations (yet) when using frame threading: Don't sync the VLCs in update_thread_context(), instead do it once during init. This fixes forgejo issue #20346 and trac issue #11592. (I don't know why 5acbdd2264d3b90dc11369f9e031e762f260882e changed submit_packet() to no longer be a no-op when draining no-delay decoders.) *: The exact condition for the crash is nb_threads > 2*nb_frames. Reviewed-by: Peter Ross Signed-off-by: Andreas Rheinhardt (cherry picked from commit 90551b7d80e39c2fcde67fc65e3623bbef12590c) >>From c83d3b98b1f82b4b2e2157f265d97d679bdef497 Mon Sep 17 00:00:00 2001 From: Andreas Rheinhardt Date: Tue, 25 Nov 2025 21:02:11 +0100 Subject: [PATCH] avcodec/vp3: Sync VLCs once during init, fix crash 6c7a344b65cb7476d1575cb1504e3a53bcbc83e7 made the VLCs shared between threads and did so in a way that was designed to support stream reconfigurations, so that the structure containing the VLCs was synced in update_thread_context. The idea was that the currently active VLCs would just be passed along between threads. Yet this was broken by 5acbdd2264d3b90dc11369f9e031e762f260882e: Before this commit, submit_packet() was a no-op during flushing for VP3, as it is a no-delay decoder, so it won't produce any output during flushing. This meant that prev_thread in pthread_frame.c contained the last dst thread that update_thread_context() was called for (so that these VLCs could be passed along between threads). Yet after said commit, submit_packet was no longer a no-op during flushing and changed prev_thread in such a way that it did not need to contain any VLCs at all*. When flushing, prev_thread is used to pass the current state to the first worker thread which is the one that is used to restart decoding. It could therefore happen that the decoding thread did not contain the VLCs at all any more after decoding restarts after flushing leading to a crash (this scenario was never anticipated and must not happen at all). There is a simple, easily backportable fix given that we do not support stream reconfigurations (yet) when using frame threading: Don't sync the VLCs in update_thread_context(), instead do it once during init. This fixes forgejo issue #20346 and trac issue #11592. (I don't know why 5acbdd2264d3b90dc11369f9e031e762f260882e changed submit_packet() to no longer be a no-op when draining no-delay decoders.) *: The exact condition for the crash is nb_threads > 2*nb_frames. Reviewed-by: Peter Ross Signed-off-by: Andreas Rheinhardt (cherry picked from commit 90551b7d80e39c2fcde67fc65e3623bbef12590c) --- libavcodec/vp3.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c index d03a1c9dbc..a021efd5d5 100644 --- a/libavcodec/vp3.c +++ b/libavcodec/vp3.c @@ -46,7 +46,6 @@ #include "decode.h" #include "get_bits.h" #include "hpeldsp.h" -#include "internal.h" #include "jpegquanttables.h" #include "mathops.h" #include "progressframe.h" @@ -2458,7 +2457,7 @@ static av_cold int vp3_decode_init(AVCodecContext *avctx) } } - if (!avctx->internal->is_copy) { + if (ff_thread_sync_ref(avctx, offsetof(Vp3DecodeContext, coeff_vlc)) != FF_THREAD_IS_COPY) { CoeffVLCs *vlcs = ff_refstruct_alloc_ext(sizeof(*s->coeff_vlc), 0, NULL, free_vlc_tables); if (!vlcs) @@ -2527,8 +2526,6 @@ static int vp3_update_thread_context(AVCodecContext *dst, const AVCodecContext * const Vp3DecodeContext *s1 = src->priv_data; int qps_changed = 0; - ff_refstruct_replace(&s->coeff_vlc, s1->coeff_vlc); - // copy previous frame data ref_frames(s, s1); if (!s1->current_frame.f || -- 2.49.1 _______________________________________________ ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org