[FFmpeg-devel] 5.0 release

[Anton Khirnov]

Quoting James Almer (2021-12-13 21:05:30)
> 
> 
> On 12/13/2021 5:01 PM, Anton Khirnov wrote:
> > 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.
> 
> I wholly agree. Hence me suggesting using AVBPrint in the meantime. It 
> certainly beats a uint8_t* + size_t combination, and it's trivial to do.

I prefer having plain-C-strings as an option - it's the common interface
everyone understands and is used to. Fancier alternatives like AVBPrint
can be provided in addition to that.

-- 
Anton Khirnov