[FFmpeg-devel] 5.0 release

[James Almer]

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.

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