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

[Nuo Mi]

On Sun, Apr 7, 2024 at 2:15 PM Anton Khirnov <anton at 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.

>
> --
> Anton Khirnov
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>