On Mon, 8 May 2017 11:41:57 -0400 Vittorio Giovara <[email protected]> wrote:
> 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. OK. Just interested because the channel mask used to prevent such things inherently. > > 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. That would be clearer, maybe even name it AV_CHAN_ZERO or AV_CHAN_SILENCE. > >> + */ > >> + 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 Well sure, that could probably be solved differently. Like, say, turning the 64 bit mask into a bit array, something like uint8_t ext_mask[20]; Which surely would cover all use-cases as well - except reordering. It would avoid the requirement for copy and free functions, so if the reordering isn't seen as a big advantage, it'd be a superior solution. (I have no particular preference.) > > 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. Well, I meant stuff like ambisonics. They don't seem to have meaningful "labels", but are essentially specific source directions from what I got. > > 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. If they add anything particularly interesting wrt. the new API, sure. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
