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? -- 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".