On Mon, May 8, 2017 at 11:58 AM, wm4 <[email protected]> wrote: > 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.
ok will amend >> >> + */ >> >> + 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. Well, that and if you don't mind fiddling with bits instead of chars ;) > (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. right, for that i "invented" a string format that seemed reasonable, but nothing prevents us from adding AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER (and similar) as a shorthand to initialize most common ambisonic layouts. >> > 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. There is a new stream disposition flag and some workarounds for aac, I'll publish them as they might be interesting. -- Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
