[FFmpeg-devel] [PATCH] avformat/mpegts: Add AVFMT_FLAG_ALLOW_CODEC_CHANGES (v2)

Pavel Koshevoy pkoshevoy at gmail.com
Fri Jul 4 08:30:43 EEST 2025


On Thu, Jul 3, 2025, 16:02 Michael Niedermayer <michael at niedermayer.cc>
wrote:

> Hi Pavel
>
> On Mon, Jun 30, 2025 at 11:39:32PM -0600, Pavel Koshevoy wrote:
> > On Mon, Jun 30, 2025, 21:46 Michael Niedermayer <michael at niedermayer.cc>
> > wrote:
> >
> > > On Mon, Jun 30, 2025 at 07:32:36PM -0600, Pavel Koshevoy wrote:
> > > > On Mon, Jun 30, 2025 at 3:46 PM Scott Theisen <
> > > > scott.the.elm-at-gmail.com at ffmpeg.org> wrote:
> > > >
> > > > > On 2025/06/29 23:55, Pavel Koshevoy wrote:
> > > > > > Make midstream AVStream.codecpar updates optional and disabled
> > > > > > by default, so that avformat API clients can enable this feature
> > > > > > explicitly when they add support for midstream codec changes.
> > > > >
> > > > > Is this signaled in any way or is the client expected to check if
> > > > > codecpar has changed?
> > > > >
> > > >
> > > > The client is expected to check codecpar for changes ...
> > >
> > > What performance impact does this have ?
> > >
> >
> > In my player?  None that I cared to measure
>
> Your player is not the only user of the libavformat API
> and with low latency audio codecs tiny packets could require
> thousands of "has anything in this AVStream changed" checks per second
>
>
> >
> >
> >
> > > also how does this align with AV_PKT_DATA_NEW_EXTRADATA
> > > and AV_PKT_DATA_PARAM_CHANGE ?
> > >
> >
> > I don't know anything about them.
>
> you do suggest to make streams change arbitrarily.
> Thats a API change, so you should first understand the existing
> related APIs
>
> Also teh design of the new API is for all user applications
>
> there needs to be a plan how to support this in ffmpeg and the muxer side
>
> The API is a puzzle piece in this plan. It must fit in, even if
> other people work on ffmpeg and the muxers.
>
> Dont you agree with that too ?
>


I have fullfilled my obligation to submit my ffmpeg changes back to the
project.  If my changes aren't good enough for everyone -- sorry, they are
good enough for me.  I don't think I'll be sending any more patches on this
topic.  Feel free to revert everything I've committed if that's better for
the project.  I'll find some other way to play these out-of-spec files.


Pavel.

>


More information about the ffmpeg-devel mailing list