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 4F61840D74 for ; Thu, 30 Dec 2021 15:27:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3B5E068AFCC; Thu, 30 Dec 2021 17:27:07 +0200 (EET) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D34C468ACC3 for ; Thu, 30 Dec 2021 17:27:00 +0200 (EET) Received: by mail-yb1-f172.google.com with SMTP id k69so57546049ybf.1 for ; Thu, 30 Dec 2021 07:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AZO0rlfrktBWQFzfCU8/l1NfxWmvF1WW5ICpYNGaM/Q=; b=avoTpuifNuSSoH1RB1tEKgU7894eT/ViX3WJcVo/StAg1HmnxmVR5H1UlsehpD1c7Q EbyekYoNyPYcu8wKKHKRECfchk4xpaVbYDsdvjnjMc8gUQgnCCQds+Uhv3Iqo8rUA5Vc bKOiKeiUw3DOcuam0JsfNGef0pBR3EzPeDxQtTdMyhSACqpdRZdbfYx/QRwBMePenXeS 11Uh+taG6clsfSdvEfg4PjlQ/vsv8MaTHgrPMqQ3elm5/QHRIXdN+ThBDqtyyw+eB8Qt 3kwS5dipjANYgELfKnSwnNGqsJjzDX6AaYVfVsNw6EA25FGibdtMMiaAL71WSq0rER+m U6Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AZO0rlfrktBWQFzfCU8/l1NfxWmvF1WW5ICpYNGaM/Q=; b=ULP5d8vZE7zOaATZJ6JZni/4oXnbZ5mkP4FC0kYsL5BFwpfJ67cQggXBDc2kgm6iNL 8+qq7rQ61dnI5HAbQjMmHoBNOEH5+PveOFuIyTQjZhdJNaslI8q2b2MKYAx7ZPnH3TgM nmlW3SZDam86ENYBRAo4klvRH0x2C8x0zjKcGKaz6g9hEz9LMuK3pQe/tRyRKSKOvLyY PXNWoJnHCdoVG1eN8aLHgj9ZgDPGrCTmcHvH3pL0ZGcWxXAbHP6QQOmMzYWyADwKrtza 089fICXH0pCmpKKXTgiWhd9/Z6tyVEXL6DtHx/1HLtYeKq4jg4D0HtbWbtlwemd+JkgW lwaA== X-Gm-Message-State: AOAM530rK3Lb2XJWGjNEOJFsUK28PP8bwbhuYN3TrjDwK1oHuu0bUDfl fNqb2PtsusI36XlMtfDN6P2c9/zeaZwUsQIYjBT4iDUc X-Google-Smtp-Source: ABdhPJxOVO+FhU5eV66SXCCSzrB5RyhG3CIVcQcSemp58yPg4uoyPKbA4TjIeGS61E3Cqi7+V1H7XXvFAAEZYKkL4n0= X-Received: by 2002:a25:3b06:: with SMTP id i6mr33870365yba.41.1640878018888; Thu, 30 Dec 2021 07:26:58 -0800 (PST) MIME-Version: 1.0 References: <20211228134929.1164-1-h.leppkes@gmail.com> <20211230150816.500-1-h.leppkes@gmail.com> <862f7804-b823-6537-9be0-fb0a3430d214@gmail.com> In-Reply-To: <862f7804-b823-6537-9be0-fb0a3430d214@gmail.com> From: Hendrik Leppkes Date: Thu, 30 Dec 2021 16:26:46 +0100 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v2] hevcdec: skip slices with missing PPS instead of skipping the entire packet 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-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: On Thu, Dec 30, 2021 at 4:13 PM James Almer wrote: > > > > On 12/30/2021 12:08 PM, Hendrik Leppkes wrote: > > Aborting decoding of the entire packet on a missing PPS can result in > > missing the actual PPS on streams with badly ordered NALs, where the > > SPS/PPS/VPS are stitched to the back of the previous frame, instead of > > the beginning of the next frame. > > > > Instead, skip the undecodable slice, and let the decoder process further > > NALs in the same packet. > > > > If this happens on the first slice, the entire frame will be discarded > > later, otherwise on other slices the decode error flag will be set to > > indicate a missing/corrupt slice. > > --- > > libavcodec/hevcdec.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c > > index 3aa70e2245..89381db240 100644 > > --- a/libavcodec/hevcdec.c > > +++ b/libavcodec/hevcdec.c > > @@ -575,7 +575,9 @@ static int hls_slice_header(HEVCContext *s) > > sh->pps_id = get_ue_golomb_long(gb); > > if (sh->pps_id >= HEVC_MAX_PPS_COUNT || !s->ps.pps_list[sh->pps_id]) { > > av_log(s->avctx, AV_LOG_ERROR, "PPS id out of range: %d\n", sh->pps_id); > > - return AVERROR_INVALIDDATA; > > + if (s->ref) > > + s->ref->frame->decode_error_flags |= FF_DECODE_ERROR_DECODE_SLICES; > > Did you check frame threading decoding with tsan after this? Touching > the output frame at this point could result in thread sync races. > > Maybe it's better to implement signaling slice decoding errors in a > separate patch that properly stores such events internally in the > per-thread context, then sets the flag in the output frame before > returning, like it's done in h264. > Like i said it's not a blocker for this fix, so it can be done later. > As far as I can tell, there is no threading issues here. There is no slice-threading here (only through wave-front parallel processing, which comes later), and no other thread would ever read or write the error field. The HEVCContext "s" is per-thread, and s->ref is accessed quite freely by the surrounding code. But I can take it out if there is any remaining concern. In reality, its quite likely that the entire frame is undecodable in this scenario anyway, and the change is only to possibly recover decoding of future frames - not partially decode this one, although that might be a bonus in some rare cases. - Hendrik _______________________________________________ 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".