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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
