Paul B Mahol (12019-10-28):
> +char *av_channel_layout_describe(const AVChannelLayout *channel_layout)
> +{
> + int i;
> +
> + switch (channel_layout->order) {
> + case AV_CHANNEL_ORDER_NATIVE:
> + for (i = 0; channel_layout_map[i].name; i++)
> + if (channel_layout->u.mask ==
> channel_layout_map[i].layout.u.mask)
> + return av_strdup(channel_layout_map[i].name);
> + // fall-through
> + case AV_CHANNEL_ORDER_CUSTOM: {
> + // max 4 bytes for channel name + a separator
> + int size = 5 * channel_layout->nb_channels + 1;
> + char *ret;
> +
> + ret = av_mallocz(size);
> + if (!ret)
> + return NULL;
> +
> + for (i = 0; i < channel_layout->nb_channels; i++) {
> + enum AVChannel ch =
> av_channel_layout_get_channel(channel_layout, i);
> + const char *ch_name = av_channel_name(ch);
> +
> + if (i)
> + av_strlcat(ret, "+", size);
> + av_strlcat(ret, ch_name, size);
> + }
> + return ret;
> + }
We can do that with AVBPrint.
> + case AV_CHANNEL_ORDER_UNSPEC: {
> + char buf[64];
> + snprintf(buf, sizeof(buf), "%d channels",
> channel_layout->nb_channels);
> + return av_strdup(buf);
> + }
> + default:
> + return NULL;
> + }
> +}
What is the user interface to designate a specific channel in a channel
layout with duplicates?
For example, I could imagine an equalizer that splits each channel into
three (low, mid, high). Then, with pan :
pan=stereo|FL=0.5*FL0+0.8*FL1+1*FL2|FR=0.5*FR0+0.8*FR1+1*FR2
Unfortunately:
- The API has nothing to specify why there are three FL channels and
thee FR channels. The possibility to attach an arbitrary label for
custom layouts should be considered.
- We need something like
idx = av_channel_layout_get_channel_by_descr(cl, "FL1");
Note: Paul, please do not take these comments as attacks against your
work. You took work that was developed in libav and ported it here, that
is a worthy achievement. But at the time it was designed, libav had
about 1.5 active developers, and they have about a quarter of our
features, and therefore of our needs. With these circumstances, it is
normal they forgot a lot of things. Our goal should be to design an API
that will be convenient to use in the long run, not to integrate their
imperfect API as fast as possible.
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".
