Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Frank Plowman <post@frankplowman.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] lavc/vvc: Invalidate PPSs which refer to a changed SPS
Date: Sat, 15 Jun 2024 17:37:52 +0100
Message-ID: <83198815-2c79-422b-a857-77f61e077825@frankplowman.com> (raw)
In-Reply-To: <CAFXK13fQHnxOopjWAnH=5wbp7WaC2dd8scB8EkXm=UphQMTORg@mail.gmail.com>

n 15/06/2024 13:24, Nuo Mi wrote:
> On Sat, Jun 15, 2024 at 2:35 PM Christophe Gisquet <
> christophe.gisquet@gmail.com> wrote:
> 
>> Le ven. 14 juin 2024, 11:39, Frank Plowman <post@frankplowman.com> a
>> écrit :
>>
>>> When the SPS associated with a particular SPS ID changes, invalidate all
>>> the PPSs which use that SPS ID.  Fixes crashes with illegal bitstreams.
>>> This is done in the CBS, rather than in libavcodec/vvc/ps.c like the SPS
>>> ID reuse validation, as parts of the CBS parsing process for PPSs
>>> depend on the SPS being referred to.
>>>
>>
>> I am uncertain about this. I have no definite knowledge nor proof, but I
>> would have thought these are persistent, IE it's legal to update some of
>> them, their validity depending on something else.
>>
> 
>> Wondering if the tested streams are thus conformant.
>>
>> But I don't know the actual rule. Maybe finding an EOB/EOS NUT? Related to
>> some particular shape of a clean random access point, that would require
>> retransmitting VPS/SPS/PPS/APS/... ?
>>
>> Asking Benjamin Bross might be a better option here.
>>
> Hi Chris,
> spec said sps should not change in a CVS.  Frank has some patches to fix a
> similar issue.
> https://github.com/FFmpeg/FFmpeg/commit/2d79ae3f8a3306d24afe43ba505693a8dbefd21b
> 
> 
> Hi Frank,
> Did it crash before your error hand code in ps.c?
> Could you send me the clip?
> 
> Thank you
> 

Hi both,

Thank you for your reviews.

An example of a crashing bitstream which is fixed by this patch is ID
295 available here: https://github.com/ffvvc/tests/pull/43.  The
relevant part of the bitstream is a sequence of NAL units

AU (decode_order=5)
18. SPS
    sps_seq_parameter_set_id = 0
    sps_ctb_log2_size_y = 5
19. PPS
    pps_pic_parameter_set_id = 0
    pps_seq_parameter_set_id = 0
20. IDR_N_LP
    ph_pic_order_cnt_lsb = 0
    NoOutputBeforeRecoveryFlag = 1
    ph_pic_parameter_set_id = 0

AU (decode_order=6)
21. AUD
22. VPS
23. SPS
    sps_seq_parameter_set_id = 0
    sps_ctb_log2_size_y = 7
24. PREFIX_APS
25. IDR_N_LP
    ph_pic_order_cnt_lsb = 0
    NoOutputBeforeRecoveryFlag = 1
    ph_pic_parameter_set_id = 0

The layout of SPSs alone is legal (not covered by the checks introduced
in 2d79ae3f8a3306d24afe43ba505693a8dbefd21b) as the second AU is a CLVSS
AU.  As a result, the bitstream crashes both before and after
2d79ae3f8a3306d24afe43ba505693a8dbefd21b.  What this patch does is
produce an error when the VCL NAL unit in the second AU (25.) tries to
use PPS ID 0, as the SPS NAL unit that PPS was defined with reference to
(18.) is no longer available.

Christophe, is my interpretation of your point correct when I say you
are suggesting that the above sequence may be legal, so long as the PPS
still satisfies the new bounds etc. derived from the second SPS?  I did
consider this, and I think it may be possible to implement by delaying
CBS element validation and inference until libavcodec/vvc/ps.c.
However, there are no bitstreams in the conformance suite which contain
such a structure and this is different to how the native HEVC decoder
behaves (see libavcodec/hevc/ps.c:72).

All the best,
-- 
Frank
_______________________________________________
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".

  reply	other threads:[~2024-06-15 16:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-14  9:37 Frank Plowman
2024-06-15  6:34 ` Christophe Gisquet
2024-06-15 12:24   ` Nuo Mi
2024-06-15 16:37     ` Frank Plowman [this message]
2024-06-16 14:11       ` Nuo Mi
2024-06-16 15:26       ` Mark Thompson
2024-06-17  7:22         ` Anton Khirnov
2024-06-17 13:23         ` Nuo Mi
2024-06-19  8:53           ` Nuo Mi
2024-06-20 12:48             ` Nuo Mi

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=83198815-2c79-422b-a857-77f61e077825@frankplowman.com \
    --to=post@frankplowman.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /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