[FFmpeg-devel] [PATCH 2/5] audioconvert: makes av_get_channel_layout accept composite names.

[Stefano Sabatini]

On date Sunday 2011-11-06 11:34:09 +0100, Nicolas George encoded:
> Le sextidi 16 brumaire, an CCXX, Stefano Sabatini a écrit :
> > I wonder if this should be something like "2channels", while a bare
> > "2" may be interpreted as the channel layout with code 2.
> 
> I believe that writing 2 for stereo is more practical and obvious than
> writing 2 for front-right. I changed it to this:
> 
>     i = strtol(name, &end, 10);
>     if (end - name == name_len)
>         return av_get_default_channel_layout(i);
>     layout = strtoll(name, &end, 0); 
>     if (end - name == name_len)
>         return layout;
> 
> Thus, "2" (decimal) will mean stereo, while "0x2" (hexadecimal) will mean
> front-right.

I still wonder if 2channels (or "2c", or "2ch" or even "2 channels"
e.g. like in "2 channels+downmix) would make for more self-explicative
descriptions. This would also make the string returned by
av_get_channel_layout_string() usable as input to
av_get_channel_layout().

But this can be extended later (with no break syntax) if you don't
like/want to implement this.

> > Nit: please meaningful names, e.g. cl and cl1 (cl-single will do)
> 
> Done: layout and layout_single.
> 
> > Note: we may want to extend the function to take a log context +
> > offset, and avoid spamming log with unwanted warnings.
> 

> That makes an API change for a very dubious reason: I would rather like to
> drop the warning altogether. What do you think?

I tend to agree.

> 
> >			      Also please document the extension
> 
> AFAIK, there is currently no documentation for the names of the channel
> layouts, and the documentation of the filters is rather inconsistent (some
> mention libavutil/chlayout.h, which does not exist, some point to the source
> code).
> 

> Where do you think this information should go? general.texi seems the
> obvious place, since it can concern any part.
> 
> (No new patch per se as there are still open issues.)

What I mean is that the function doxy should mention the supported
syntax, even if not in a complete way (one sentence referring the
list of accepted channel names in audioconvert.c may do).

For what regards user documentation, maybe we could have a
libavutil.texi file documenting stuff specific to libavutil and which
doesn't have a specific section (e.g. eval stuff, parsing utilities,
etc.). Alternatively a dedicated channel_layout.texi section may do as
well. Having some way to expose the accepted names (e.g. through a
command line list command) would be nice, but missing that a reference
to the source code or even the function used is better than nothing.
 
> Regards,
-- 
FFmpeg = Fanning and Friendly Mystic Philosofic Enhancing Game