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 619844514D for ; Tue, 10 Jan 2023 07:31:26 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0C8CD68BC8B; Tue, 10 Jan 2023 09:31:24 +0200 (EET) Received: from out162-62-57-252.mail.qq.com (out162-62-57-252.mail.qq.com [162.62.57.252]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9F5D268807F for ; Tue, 10 Jan 2023 09:31:16 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1673335872; bh=JBkXu+7zf/U325cYq/0ZJ5u5UQe12iI87xWgywUz7SA=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=wvbIABL4LtO2HhW1/jYah2B4E3HkHrAX14E3Vnnr1Hr1UCaEkvaHNi78YlvPsGppi wqwBzYWYvUwtc1MzPUdPK8VqvREx5TfNCo3/1di3enYFMbIdeseTQ2OYdNSrnZxrp1 zbuAIiqdauhgyNYMHyke2JC89hsHncgAp8t0wb20= Received: from zhilizhao-LC3 ([59.37.125.102]) by newxmesmtplogicsvrszb6-0.qq.com (NewEsmtp) with SMTP id 7CBBBA9D; Tue, 10 Jan 2023 15:31:11 +0800 X-QQ-mid: xmsmtpt1673335871tbbq07eqg Message-ID: X-QQ-XMAILINFO: OZZSS56D9fAjpTM4SEa2iYfEcagPTbp8R7vsUaxm73McUD+kZHSp+lheXVqROr tACgyItGepFv7DFRjp7QxrZCW9zY3YPhKzX66h4oQUC89o3IzS57ervh42QqmzDgT99crLymcm43 1IY2Y8w/0HRYlt2Xe/h0CUljXWtttbqax1jBsOn9NXRwcCBUdViU1lGu7OZRN0dAL3Xf8cLV00Cp OsHWPklvDr4FjtDpg+L0NacthmD9zrpHtUdeTKAetP2WeuSY7pgNBs0uFCZi07Fh40MDfyChlXOg +02QOkZgAdDOI/Qrf7Yn+DsAT4bskIZkEFz5vnLb6zN0e/l9vPEbMHQGZ9X9zqvsaW6gytnV/svo p1XoDrvKOVrPc5luBG7PAPjoByANaELsMdLAWMoVDnyvbylUvPPsgOAZfso7aQCCLv3mZY665UVr /BI0IDtLTCDpFCuyu7Mz3Y8N+sv1PqnvOWZX00ygjj64kIBybXJN6L5ar/9A2pdCpzeC71lZBpVT apA5+f1Uh+yko7C5DeH/6gtR9VL9QrcK3wrPG+FjlXZQr/bhxYTGBO/TBZnr+pEguiTtXcEc6eJx zydeyAhhzxjnLW6HPmML/Z3Du57CwCiTaD8klfcNmspQswDEqrpucVmYGh93pquEaeqcJHcO5cU7 HJz1qWzzP4ST9a9yDourIms9d92tGsjqzSkb+HvkxQso0/dVUw71RDcw/34CpZqmQfD0nDlrCWw7 mO1H1uw4wpKCntXfbIJNcFx7jPkxJrbNWKCbXUIaPNp4z/5OLYa3gkAkfwgGJW9VNT3IBMEy6lDl /dlxEubgi7NhVVjnEp1CuNMu4wrsk/MFsih5X6BYwDEfMVBCzkXLFXKaPQiM8l3lBBrNZax7+fKF nSqgkBJYvhsA0relEBks6dN/bM7moXrr7GWLZP2hDh1mI5hMt+FKpDricK97OnJp6xMs/dNdYSYK I92dMCszMFLg0b8yU9Krgd69yy0JWdMdjIf0xmq2jCAUKGUr29sw== X-OQ-MSGID: <4a00bbd4e10174eac33a4e8469dd5adcddee8cf0.camel@foxmail.com> From: Zhao Zhili To: ffmpeg-devel@ffmpeg.org Date: Tue, 10 Jan 2023 23:31:14 +0800 In-Reply-To: References: User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: fix missing SPS/PPS to IDR frames 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: On Tue, 2023-01-10 at 07:41 +0100, Andreas Rheinhardt wrote: > Zhao Zhili: > > From: Zhao Zhili > > > > If there is a single group of SPS/PPS before an IDR frame, but no > > SPS/PPS after that, we will miss the chance to reset > > idr_sps_seen/idr_pps_seen. The result is missing SPS/PPS for all > > IDR frames except the first one. > > > > Signed-off-by: Zhao Zhili > > --- > > libavcodec/h264_mp4toannexb_bsf.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/h264_mp4toannexb_bsf.c > > b/libavcodec/h264_mp4toannexb_bsf.c > > index d11be455c2..bbdeca9c44 100644 > > --- a/libavcodec/h264_mp4toannexb_bsf.c > > +++ b/libavcodec/h264_mp4toannexb_bsf.c > > @@ -259,7 +259,7 @@ static int h264_mp4toannexb_filter(AVBSFContext > > *ctx, AVPacket *opkt) > > > > count_or_copy(&out, &out_size, buf, nal_size, > > unit_type == H264_NAL_SPS || unit_type > > == H264_NAL_PPS, j); > > - if (!new_idr && unit_type == H264_NAL_SLICE) { > > + if (unit_type == H264_NAL_SLICE) { > > new_idr = 1; > > sps_seen = 0; > > pps_seen = 0; > > If I understand you correctly, you want that to include the parameter > sets from the extradata to every IDR frame without extradata if said > IDR > frame follows a non-IDR frame after in-band parameter sets. There is > just one problem with this: Said in-band parameter sets might > overwrite > parameter sets from extradata and inserting the outdated parameter > sets > from extradata lateron might make the stream undecodable. It's a good question. Current code works when an IDR has in-band parameter set, which is different than the out-of-band parameter set, and the decoder doesn't miss the in-band parameter set. But there is a high chance the decoder will miss the in-band parameter set for annexb bitstream, e.g., playback at the middle of a live mpegts streams. It's a serious issue of missing periodic in-band parameter set for annexb for a lot of usecases. Handle new parameter set isn't as common as the need of periodic in-band parameter set (I guess). It's not a new issue that this bitstream failed to update the parameter set, for example, it doesn't handle AV_PKT_DATA_NEW_EXTRADATA. I can add support for 1. handling AV_PKT_DATA_NEW_EXTRADATA 2. handling in-band sps/pps But it won't be soon. > > - Andreas > > _______________________________________________ > 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". _______________________________________________ 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".