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

[Nicolas George]

Anton Khirnov (12020-02-25):
> As far as I can tell, the Apple API linked above does not support that
> either. The way of describing the channel layout is given by
> mChannelLayoutTag, which can be either
> - kAudioChannelLayoutTag_UseChannelBitmap, which is effectively
>   equivalent to our current API, or the new API's LAYOUT_NATIVE
> - one of several predefined layouts, which can be mapped either to
>   LAYOUT_NATIVE or LAYOUT_CUSTOM
> - kAudioChannelLayoutTag_UseChannelDescriptions, which cannot be
>   represented in the current API, but is effectively equivalent to the
>   new API's LAYOUT_CUSTOM
>   The AudioChannelDescription struct contains:
>     * AudioChannelFlags, which apply to coordinates
>     * three floats, which are the coordinates
>     * AudioChannelLabel, which is uint32 similar to our AVChannel
> 
> I see no support for any custom free-form text labels of the kind you
> want me to add.

The link above does not describe an API, it describe a format. A format
that can contain several channels with the FL (example) disposition.
Even if there are no labels attached, users need an interface to specify
one: "the first FL channel", "the second FL channel", for example. Your
proposal does not have it, it needs it.

> In addition to Hendrik's reply (which I agree with), support for this
> can be later added through a new layout type if someone really needs it.
> I see no reason to spend effort implementing functionality that is not
> actually used for anything.

It's the second time you propose to extend the API later like that. I am
glad you realize the API you proposed is insufficient and needs
extending, but I am worried that you don't realize that extending later
for needs that we see now is a terrible idea.

It's a terrible idea because it requires more work, and because the
extension will always stay second class compared to the initial code,
and unsupported in all the places in the code that will not be updated
for it.

Since we were lucky to see we need a way of attaching data to channels
before including the API, we'll include it in the API from the start.

It's too bad it will require dynamic allocation and make the handling of
the structure as a whole more clumsy, but it seems it was unavoidable.

We could use simply a per-channel metadata dictionary, it would allow
both the speaker coordinate in this spec and the free-form label that I
want. Alternatively, we can use a more typed approach, like side data.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200226/1f77f48a/attachment.sig>