Re: [FFmpeg-devel] [PATCH v2] lavc/vvc: Error if SPS ID is duplicated within CVS

[Anton Khirnov <anton@khirnov.net>]

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?

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