[FFmpeg-devel] 5.0 release

[Anton Khirnov]

Quoting James Almer (2021-12-13 20:51:05)
> 
> 
> On 12/13/2021 4:47 PM, Anton Khirnov wrote:
> > Quoting James Almer (2021-12-13 20:04:34)
> >>
> >>
> >> On 12/13/2021 3:05 PM, Jean-Baptiste Kempf wrote:
> >>> On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
> >>>> If you know of any major issues which need to be done before the release do them
> >>>> now. If you know of any issues which are release-blocking list them in a reply
> >>>> here please.
> >>>
> >>> Maybe the audio channel layout would be nice to settle before?
> >>
> >> There are two or three requests/blockers, by Nicolas and i think Lynne.
> >>
> >> - The request to have either a string to give custom channels a name, or
> >> at least an opaque pointer per channel that can be used for such
> >> purpose. This has seen opposition from Anton.
> > 
> > I do not oppose an opaque id, as long as it's not too big. I do oppose a
> > string though, as it would require extra allocations per channel.
> > 
> >> - The request to wait for a new string handling API to land and be used
> >> for the relevant functions in this set. This has not seen opposition
> >> from anyone yet, but it's not very feasible if said new API is not yet
> >> in a state beyond a draft/RFC. It would delay this set indefinitely. We
> >> can use AVBPrint in the meantime, and name the functions in a way that
> >> reflects it, to leave the cleaner names for the future API.
> > 
> > I said this before, but let me state again that I oppose this for
> > various reasons.
> 
> Using AVBPrint (or any other string API altogether), or introducing 
> functions that will eventually be replaced?

I am very much against arguments along the lines of "your work cannot
progress until my pet project is done". This is not how development here
should function.

Also, AFAIU Nicolas wants this new string handling API in order to put
in per-channel string identifiers. I am against those as well.

-- 
Anton Khirnov