Re: [FFmpeg-devel] [PATCH 2/2] avformat/concatdec: Check recursion depth

From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/concatdec: Check recursion depth
Date: Mon, 14 Jul 2025 21:34:26 +0200
Message-ID: <20250714193426.GN29660@pb2> (raw)
In-Reply-To: <26fb4b10-b69e-31a5-e2ae-c787395f7e48@passwd.hu>

[-- Attachment #1.1: Type: text/plain, Size: 1867 bytes --]

On Sun, Jul 13, 2025 at 07:09:13PM +0200, Marton Balint wrote:
> 
> 
> On Fri, 11 Jul 2025, Michael Niedermayer wrote:
> 
> > On Fri, Jul 11, 2025 at 10:29:30AM +0200, Nicolas George wrote:
> > > Michael Niedermayer (HE12025-07-11):
> > > > ok, chanegd it to AVERROR_INVALIDDATA
> > > 
> > > Thanks.
> > > 
> > > > Yes
> > > > but this also affects releases, and adding a field to AVFormatContext
> > > > is an issue for releases as it changes ABI
> > > > 
> > > > So the concat patch would go into old release branches and the
> > > > AVFormatContext one into master
> > > > Unless someone has a better idea ...
> > > 
> > > What happened to being able to add fields at the end?
> > 
> > a release branch might have a libavformat with version
> > 1.2.3
> > 
> > the next release branch  might have a libavformat with version
> > 1.5.2
> > 
> > The problem is if we add a field to 1.2.3 (which would become 1.3.0)
> > ABI/API requires that field to be in 1.5.2, but it is not
> > 
> > Also besides this problem, 1.3.0 on git masters history likely
> > added something thats not on the release branches 1.3.0
> > 
> > So, adding at the end is perfectly fine on the linear history
> > on git master but our release branches, branch off that.
> > 
> > so we would have to hack around things if we really needed to
> > add a field, we could try to use 1.2.4 or even 1.2.3 with a new field
> > but this is wrong.
> 
> I always assumed that the whole point of bumping minor versions both before
> and after the release is to be able to bump micro in release branches if new
> option or a new public field is added in the release branch.

it could be (ab)used that way, yes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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