Hi Pavel On Mon, Jun 30, 2025 at 11:39:32PM -0600, Pavel Koshevoy wrote: > On Mon, Jun 30, 2025, 21:46 Michael Niedermayer > 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@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 ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.