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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
