On Fri, May 5, 2017 at 11:13 PM, wm4 <[email protected]> wrote: > On Fri, 5 May 2017 22:20:18 -0400 > Vittorio Giovara <[email protected]> wrote: > > >> +enum AVChannelOrder { >> + /** >> + * The native channel order, i.e. the channels are in the same order in >> + * which they are defined in the AVChannel enum. This supports up to 63 >> + * different channels. >> + */ >> + AV_CHANNEL_ORDER_NATIVE, >> + /** >> + * The channel order does not correspond to any other predefined order >> and >> + * is stored as an explicit map. For example, this could be used to >> support >> + * layouts with 64 or more channels. >> + */ >> + AV_CHANNEL_ORDER_CUSTOM, >> + /** >> + * Only the channel count is specified, without any further information >> + * about the channels. >> + */ >> + AV_CHANNEL_ORDER_UNSPEC, >> +}; > > >> +typedef struct AVChannelLayout { >> + /** >> + * Channel order used in this layout. >> + */ >> + enum AVChannelOrder order; >> + >> + /** >> + * Number of channels in this layout. Mandatory field. >> + */ >> + int nb_channels; >> + >> + /** >> + * Details about which channels are present in this layout. >> + * For AV_CHANNEL_ORDER_UNSPEC, this field is undefined and must not be >> + * used. >> + */ >> + union { >> + /** >> + * This member must be used for AV_CHANNEL_ORDER_NATIVE. >> + * It is a bitmask, where the position of each set bit means that >> the >> + * AVChannel with the corresponding value is present. >> + * >> + * I.e. when (mask & (1 << AV_CHAN_FOO)) is non-zero, then >> AV_CHAN_FOO >> + * is present in the layout. Otherwise it is not present. >> + * >> + * @note when a channel layout using a bitmask is constructed or >> + * modified manually (i.e. not using any of the av_channel_layout_* >> + * functions), the code doing it must ensure that the number of set >> bits >> + * is equal to nb_channels. >> + */ >> + uint64_t mask; >> + /** >> + * This member must be used when the channel order is not native, >> and >> + * represents a nb_channels-sized array. Its semantics may >> depending on >> + * the channel order. >> + * >> + * - For AV_CHANNEL_ORDER_CUSTOM: each element signals the presence >> of >> + * the AVChannel with the corresponding value: eg. when map[i] is >> + * equal to AV_CHAN_FOO, then AV_CHAN_FOO is the i-th channel in >> + * the audio data. > > Does it allow a channel to be mapped more than once?
I think so, yes, it's caller responsibility to ensure that the data filled is correct. > Does it allow > padding channels (that would be all-0)? The unspec order allows to do almost anything, so if your map contains 0 the channel should/can be ignored. If you think it's clearer maybe we could introduced a AV_CHAN_PAD for this case. >> + */ >> + uint8_t *map; >> + } u; >> +} AVChannelLayout; > > So AV_CHANNEL_ORDER_CUSTOM is as powerful as AV_CHANNEL_ORDER_NATIVE, > just that it allows an arbitrary order? yes, and it allows to map more than 63 channels > How would layouts that don't fit into the channel label schema be > handled? Do you mean those layouts that cannot be converted with av_channel_layout_from_string()? You could use the API directly or we could agree on some form of syntax for this particular case. > How would that ambisonic stuff be represented? I mentioned the patch to my branch in the cover letter, Luca was kind enough to forward it to the mailing list (<[email protected]>). Even though ambisonic wasn't the sole reason for this api break, I can send the final part of the set containing the opus and mp4 implementations if that would help. Cheers -- Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
