[FFmpeg-devel] Channel layouts (was: [PATCH] lavfi: store and propagate number of channels information in audio buffer properties)

Michael Niedermayer michaelni at gmx.at
Mon Nov 12 00:19:06 CET 2012


On Sun, Nov 11, 2012 at 09:10:37PM +0100, Nicolas George wrote:
> On 2012-11-11, I wrote:
> <snip>
> Short version:
> For streams with strange channel layouts, we need an immediate workaround
> and a long-term solution.

We need the channel number. We have a patch that solves this
for the long term in a very simple and clean way.

Problem is we need to know the size of the array, its a security matter
The array size is the channel count EVERYWHERE in libavcodec and
libavformat and ffmpeg*.c ffplay*.c libavdevice and others.
Its a major issue if its done differently in libavfilter, it will be
a neverending source of bugs if this is done differently in

The question or rather what i dont get is what problem (if any) this
trivial patch has?

> Immediate workaround I just thought of:
> #define AV_CH_STRANGE_UNKNOWN        0x0000800000000000ULL
> (this bit is far away from any other already defined channel)
> With the rule: if this channel is set in a channel layout, then the channel
> layout as a whole is "strange/unknown". If we need to define a n-channels
> strange/unknown layout, we just make one using this bit and n-1 other bits
> (using preferably unused bits).
> Then we can have:
> int av_fix_channel_layout(void *log, int count, uint64_t *layout)
> {
>     if (count != av_get_channel_layout_nb_channels(*layout)) {
> 	av_log(log, AV_LOG_WARNING, "...");
> 	*layout = 0;
>     }
>     if (!*layout)
> 	layout = av_make_strange_channel_layout(count);
> }
> and use it all over the place.
> Clearly, it is a hack, but I believe it is a robust one that does not cause
> any problem.

I want to store more than 64 channels, nothing you suggest allows this
how can this hack even be related to a solution, it plain and simple
does not solve it.
and 64 doesnt work either due to various special bits and special

i want 8 mono channels or 4 stereo channels and i want to be able
to know which.
Add a channel count and the channel layout will just tell us which
your system will mark either as "7.1 strange"
No muxer can make any sense of "7.1 strange"
but with a channel count we can just preserve the layout as it IS
from the input file. with your hack we have no place to preserve then
TRUELY stored channel layout because you would use the layout as
nothing but a channel count.

I want a channel count so i KNOW how many entries i can address
this is a security issue, i do not want a complex way how to find it
out from metadata, i simply want a field that tells me how many
channels there are, something one can assert on, something one can
test an index against. NOT something that in libavcodec means A
and in libavfilter means B

> And it is not a long-term solution, since it can not express some
> information that the demuxer or decoder can have, like "these 2 channels are
> not stereo, they are mono/Japanese + mono/English". Looks like we will need
> per-channel metadata, yay!

100% unrelated to this thread, but yes that may become needed in some


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121112/35a6c25d/attachment.asc>

More information about the ffmpeg-devel mailing list