On Sun, Apr 7, 2024 at 8:16 PM Anton Khirnov <an...@khirnov.net> wrote:
> Quoting Nuo Mi (2024-04-07 14:13:58) > > On Sun, Apr 7, 2024 at 2:15 PM Anton Khirnov <an...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
