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

[Marton Balint <cus@passwd.hu>]

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?

>
> 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".