From: Nuo Mi <nuomi2021@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>, Frank Plowman <post@frankplowman.com> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/vvc: Error if SPS ID is duplicated within CVS Date: Sun, 7 Apr 2024 21:04:37 +0800 Message-ID: <CAFXK13d8kp4ARh0qFkJbO0_9+bRtTypc5a3OyANrw+aVgNOZuw@mail.gmail.com> (raw) In-Reply-To: <171249217232.30127.8333600895527168051@lain.khirnov.net> On Sun, Apr 7, 2024 at 8:16 PM Anton Khirnov <anton@khirnov.net> wrote: > Quoting Nuo Mi (2024-04-07 14:13:58) > > On Sun, Apr 7, 2024 at 2:15 PM Anton Khirnov <anton@khirnov.net> wrote: > > > > > Quoting Frank Plowman (2024-04-06 15:46:09) > > > > Key line from the spec is: > > > > > > > > "All SPS NAL units with a particular value of > sps_seq_parameter_set_id > > > > in a CVS shall have the same content." > > > > > > > > Prior to this patch, the VVC decoder's behaviour on encountering a > > > > duplicated SPS ID (within the entire bitstream, not restricted to > > > > a CVS) was simply to replace the entry in the SPS lookup table with > the > > > > new data. Illegal bitstreams with multiple SPSs in the same CVS > sharing > > > > an ID but differing elsewhere could cause all manner of issues. > > > > > > > > The patch tracks which SPS IDs have been used in the given CVS using > the > > > > new sps_id_used field of VVCParamSets. If it encounters an SPS with > an > > > > ID already in use and whose content differs from the previous SPS, it > > > > throws an AVERROR_INVALIDDATA. > > > > > > I wonder if it wouldn't be better to do what H264/HEVC do, which is > > > replace the SPS, invalidate the PPSes that depend on the old one, and > > > start a new CVS. > > > > > Consider two scenarios: > > If the first SPS is incorrect, the entire CVS is undecodable because the > > key frame is wrong, no matter what we do. > > If the second SPS is incorrect, H.264/HEVC can't recover until the next > CVS > > because it replaces the correct SPS with the wrong one. However, the > > current VVC logic allows for recovery in such cases. > > Therefore, in the second case, the current logic may have benefits. > > Could the new SPS not signal the start of a new CVS? > Yes. Take AUD_A_Broadcom_3.bit as an example, the nal order is SPS PPS IDR_N_LP TRAIL MORE TRAILS... SPS PPS CRA TRAIL MORE TRAILS... SPS PPS IDR_N_LP The SPS before CRA will not start a new CVS, unless you seek to the CRA. > > -- > 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". > _______________________________________________ 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".
prev parent reply other threads:[~2024-04-07 13:05 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-06 13:46 Frank Plowman 2024-04-07 2:39 ` Nuo Mi 2024-04-07 6:15 ` Anton Khirnov 2024-04-07 12:13 ` Nuo Mi 2024-04-07 12:16 ` Anton Khirnov 2024-04-07 13:04 ` Nuo Mi [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAFXK13d8kp4ARh0qFkJbO0_9+bRtTypc5a3OyANrw+aVgNOZuw@mail.gmail.com \ --to=nuomi2021@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ --cc=post@frankplowman.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git