Re: [FFmpeg-devel] [PATCH 000/279 v2] New channel layout API

[James Almer <jamrial@gmail.com>]

On 12/16/2021 9:04 PM, Marton Balint wrote:
> 
> 
> On Thu, 16 Dec 2021, James Almer wrote:
> 
>> Resending the first two patches only, since this is meant to
>> show the implementation of one of the several suggestions made
>> in the previous set that need to be discussed and hopefully
>> resolved in a call.
> 
> Can you push the full branch somewhere?

Just force pushed the latest version to the same repo as last time in 
https://github.com/jamrial/FFmpeg/commits/channel_layout

> 
>>
>> The proposals so far to extend the API to support either custom
>> labels for channels are, or some form of extra user information.
>>
>> - Fixed array of bytes to hold a label. Simple solution, but
>>  the labels will have a hard limit that can only be extended
>>  with a major bump. This is what i implemented in this version.
>> - "char *name" per channel that the user may allocate and the
>>  API will manage, duplicate and free. Simple solution, and the
>>  name can be arbitrarily long, but inefficient (av_strdup() per
>>  channel with a custom label on layout copy).
>> - "const char *name" per channel for compile time constants, or
>>  that the user may allocate and free. Very efficient, but for
>>  non compile time strings ensuring they outlive the layout can
>>  be tricky.
>> - Refcounted AVChannelCustom with a dictionary. This can't be
>>  done with AVBufferRef, so it would require some other form
>>  of reference counting. And a dictionary may add quite a bit of
>>  complexity to the API, as you can set anything on them.
> 
> Until we have proper refcounting API we can make the AVBufferRef in 
> AVChannelLayout a void *, and only allow channel_layout functions to 
> dereference it as an AVBufferRef. This would mean adding some extra 
> helper functions to channel layout, but overall it is not unsolvable.
> 
> The real question is that if you want to use refcounting and add helpers 
> to query / replace per-channel metadata, or you find the idea too heavy 
> weight and would like to stick to flat structs.
> 
>> - Opaque id/s or pointer/s that the API will not touch beyond
>>  passing them around (So unlike the above, the helpers would not
>>  benefit from this). This can be combined with any of the above,
>>  too, and i did as much in this version.
>> - Leave API as it was in v1.
> 
> Maybe it is not said enough times, but thanks to everybody who worked on 
> this. It certainly was huge work, and I know that it is a thankless 
> effort to get such a big change merged. Any change based on my 
> suggestions is appreciated, even if some of my ideas get rejected in the 
> end.
> 
> Thanks,
> Marton
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".