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

[Nicolas George]

Le primidi 21 brumaire, an CCXXI, Michael Niedermayer a écrit :
> nicolas, stefano, ubitux any comments ?

I take this opportunity to mention the test you recently added to
lavfi/avcodec to check that channel count and layout are consistent.

I may have given you the impression that this test was wrong, but I do not
believe it is. Well, just a little bit: the problem is not "libavfilter does
not support", the problem is "the channel layout is bogus".

My point is that whenever both a channel count and a channel layout are
present, they MUST be consistent. Obviously, they are not at the output of
the truehd decoder, and this should be fixed. It also should be detected
much earlier. Probably directly in avcodec_decode_audio4:

    if (ret >= 0 && *got_frame_ptr) {
	av_assert1(!frame->channel_layout ||
	           frame->channels == av_get_channel_layout_nb_channels(frame->channel_layout));
    }

You also mention files that contain extended layouts that can not be
expressed with the bit mask of the channel_layout field. Well, we knew that
a bit mask was a very limited data structure; it was enough for some time,
but if this kind of codec start to appear, it is no longer, and we should
start thinking about what to use instead.

A few pointers to files with that kind of strange layouts would be very
useful for starters. You pointed this one:
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd
It starts with this warning:
[truehd @ 0x13f2f60] Mono stream with 2 substreams, ignoring 2nd
but the second substream is not really ignored.


Channel layouts are a treacherous issue: most sample files are stereo, and
most developers use stereo speakers or headphones, so it is easy to not care
about them; but more and more programs exist with surround sound and more
and more people have the hardware to play them. Having the center speaker
playing the rear-left channel gives a very bad image to the software
involved.

Regards,

-- 
  Nicolas George
-------------- 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/20121111/6ae2ef87/attachment.asc>