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 B01E543342 for ; Sat, 2 Jul 2022 08:35:02 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4088468B851; Sat, 2 Jul 2022 11:34:58 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7AFA968B736 for ; Sat, 2 Jul 2022 11:34:51 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id DACFF240179; Sat, 2 Jul 2022 10:34:50 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 9RUJ4jNq4LP5; Sat, 2 Jul 2022 10:34:49 +0200 (CEST) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 832B92400F5; Sat, 2 Jul 2022 10:34:49 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id A506A1601B2; Sat, 2 Jul 2022 10:34:49 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDB6PR0101MB22142A7A49F01D9EB61518608FBA9=40DB6PR01?= =?utf-8?q?01MB2214=2Eeurprd01=2Eprod=2Eexchangelabs=2Ecom=3E?= References: =?utf-8?q?=3CDB6PR0101MB2214B28F90001024D646E62B8FBA9=40DB6PR010?= =?utf-8?q?1MB2214=2Eeurprd01=2Eprod=2Eexchangelabs=2Ecom=3E_=3CDB6PR0101MB2?= =?utf-8?q?2142A7A49F01D9EB61518608FBA9=40DB6PR0101MB2214=2Eeurprd01=2Eprod?= =?utf-8?q?=2Eexchangelabs=2Ecom=3E?= Mail-Followup-To: FFmpeg development discussions and patches , Andreas Rheinhardt Date: Sat, 02 Jul 2022 10:34:49 +0200 Message-ID: <165675088963.31466.628326916294051579@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 09/18] avcodec/hevcdec: Add stat_coeffs to HEVCABACState 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 Cc: Andreas Rheinhardt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Andreas Rheinhardt (2022-07-01 00:29:40) > The HEVC decoder has both HEVCContext and HEVCLocalContext > structures. The latter is supposed to be the structure > containing the per-slicethread state. > > Yet that is not how it is handled in practice: Each HEVCLocalContext > has a unique HEVCContext allocated for it and each of these > coincides with the main HEVCContext except in exactly one field: > The corresponding HEVCLocalContext. > This makes it possible to pass the HEVCContext everywhere where > logically a HEVCLocalContext should be used. > > This led to confusion in the first version of what eventually became > commit c8bc0f66a875bc3708d8dc11b757f2198606ffd7: > Before said commit, the initialization of the Rice parameter derivation > state was incorrect; the fix for single-threaded as well as > frame-threaded decoding was to add backup stats to HEVCContext > that are used when the cabac state is updated*, see > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/268861.html > Yet due to what has been said above, this does not work for > slice-threading, because the each HEVCLocalContext has its own > HEVCContext, so the Rice parameter state would not be transferred > between threads. > > This is fixed in c8bc0f66a875bc3708d8dc11b757f2198606ffd7 > by a hack: It rederives what the previous thread was and accesses > the corresponding HEVCContext. > > Fix this by treating the Rice parameter state the same way > the ordinary CABAC parameters are shared between threads: > Make them part of the same struct that is shared between > slice threads. This does not cause races, because > the parts of the code that access these Rice parameters > are a subset of the parts of code that access the CABAC parameters. > > *: And if the persistent_rice_adaptation_enabled_flag is set. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/hevc_cabac.c | 17 ++++++++--------- > libavcodec/hevcdec.c | 10 +++++----- > libavcodec/hevcdec.h | 10 +++++++--- > 3 files changed, 20 insertions(+), 17 deletions(-) > > diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c > index a194f8a02a..985c97ef2a 100644 > --- a/libavcodec/hevc_cabac.c > +++ b/libavcodec/hevc_cabac.c > @@ -453,19 +453,18 @@ void ff_hevc_save_states(HEVCContext *s, int ctb_addr_ts) > (ctb_addr_ts % s->ps.sps->ctb_width == 2 || > (s->ps.sps->ctb_width == 2 && > ctb_addr_ts % s->ps.sps->ctb_width == 0))) { > - memcpy(s->cabac_state, s->HEVClc->cabac_state, HEVC_CONTEXTS); > + memcpy(s->cabac->state, s->HEVClc->cabac_state, HEVC_CONTEXTS); So if I'm reading this right, this copies the per-slice-context state into the decoder-global state. And it's done from slice threads with no locks. So how is this not racy? -- Anton Khirnov _______________________________________________ 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".