[FFmpeg-devel] [PATCH 001/279] Add a new channel layout API

[Lynne]

14 Dec 2021, 09:32 by cus at passwd.hu:

>
>
> On Tue, 14 Dec 2021, Lynne wrote:
>
>> 14 Dec 2021, 02:13 by cus at passwd.hu:
>>
>>>
>>>
>>> On Tue, 7 Dec 2021, James Almer wrote:
>>>
>>> I would like to attach some extendable, possibly per-channel metadata to the channel layout. I'd rather put it into AVChannelLayout, so native layouts could also have metadata. This must be dynamically allocated to make it extendable and to not consume too many bytes. I can accept that it will be slow. But I don't see it unmanagable, because AVChannelLayout already have functions for allocation/free/copy. I also think that most of the time it will not be used (e.g. if metadata is NULL, that can mean no metadata for all the channels).
>>>
>>> If we can't decide what this should be, array of AVDictionaries, some side-data like approach but in the channel layout, or a new dynamically allocated AVChannelLayoutMetadata struct, then maybe just reserve a void* in the end of the AVChannelLayout, and we can work it out later.
>>>
>>
>> The idea to use opaque indices is IMO better. You can store any
>> metadata you want into the frame->opaque(_buf) field, and it'll
>> be completely copied of av_frame_ref().
>> If we go for an opaque pointer, I'd like for it to be copied (by
>> value, not data) into any ref'd frames. I'd prefer an opaque
>> field over an opaque metadata field.
>>
>
> It's not just frames which have channel layouts, but AVCodecParameters, AVStreams or AVFilterLinks. It is not the user defined metadata we have a problem storing/getting, but framework (demuxer, filter) defined metadata.
>

In that case, I think it's fine to have a dictionary metadata field in
the per-channel struct, It'll increase the struct size slightly, but I think
it's acceptable.

I think this discussion would go a lot quicker if we could discuss this
on IRC, would you and Nicolas mind joining and pinging me and elenril
so we could settle the details?