-ac downmix fails.

[Mista_D]

"-AC 2" filter doesn't downmix properly. The output has surround channels only.

Source sample: ​https://www.dropbox.com/s/dvurxjsjbu3f3fk/disk11.ts?m

ffmpeg -i disk11.ts -ac 2 -t 100 100.mp4

ffmpeg version 2.0 Copyright (c) 2000-2013 the FFmpeg developers

built on Aug 6 2013 16:10:49 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-52)
configuration: --enable-static --enable-postproc --enable-gpl --enable-avfilter --enable-libx264 --enable-libxvid --enable-libmp3lame --enable-libfaac --enable-pthreads --enable-swscale --enable-runtime-cpudetect --disable-devices --disable-avdevice --extra-ldflags=-static --disable-shared --enable-bzlib --enable-zlib --extra-libs='-lx264 -lxvidcore -lmp3lame -lpthread -lm -lbz2 -lz -lpthread -lvpx -lass -lfontconfig -lexpat -lfreetype -lfaac' --disable-encoder=libgsm --disable-decoder=libgsm --disable-doc --enable-libvpx --enable-libass --enable-version3 --enable-nonfree --enable-libfreetype
libavutil 52. 38.100 / 52. 38.100
libavcodec 55. 18.102 / 55. 18.102
libavformat 55. 12.100 / 55. 12.100
libavfilter 3. 79.101 / 3. 79.101
libswscale 2. 3.100 / 2. 3.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 3.100 / 52. 3.100

Input #0, mpegts, from 'disk11.ts':

Duration: 01:38:47.88, start: 0.221700, bitrate: 59026 kb/s
Program 1

Stream #0:0[0x1e1]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
Stream #0:1[0x1e2]: Audio: s302m (BSSD / 0x44535342), 48000 Hz, 8 channels (FL+FR+FC+LFE+BL+BR+DL+DR), s16, 7680 kb/s

[libx264 @ 0xc410c40] using SAR=1/1
[libx264 @ 0xc410c40] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
[libx264 @ 0xc410c40] profile High, level 4.0
[libx264 @ 0xc410c40] 264 - core 135 - H.264/MPEG-4 AVC codec - Copyleft 2003-2013 - ​http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to '100.mp4':

Metadata:

encoder : Lavf55.12.100
Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 24k tbn, 23.98 tbc
Stream #0:1: Audio: aac (libfaac) ([64][0][0][0] / 0x0040), 48000 Hz, stereo, s16, 128 kb/s

Stream mapping:

Stream #0:0 -> #0:0 (mpeg2video -> libx264)
Stream #0:1 -> #0:1 (s302m -> libfaac)

Press [q] to stop, ? for help
frame= 2398 fps= 20 q=-1.0 Lsize= 38380kB time=00:01:40.01 bitrate=3143.7kbits/s dup=3 drop=0
video:36750kB audio:1563kB subtitle:0 global headers:0kB muxing overhead 0.175016%
[libx264 @ 0xc410c40] frame I:15 Avg QP:14.89 size: 56463
[libx264 @ 0xc410c40] frame P:961 Avg QP:21.33 size: 28671
[libx264 @ 0xc410c40] frame B:1422 Avg QP:22.22 size: 6492
[libx264 @ 0xc410c40] consecutive B-frames: 11.4% 26.1% 7.3% 55.2%
[libx264 @ 0xc410c40] mb I I16..4: 38.8% 58.7% 2.5%
[libx264 @ 0xc410c40] mb P I16..4: 5.0% 13.5% 0.4% P16..4: 35.7% 9.1% 4.1% 0.0% 0.0% skip:32.2%
[libx264 @ 0xc410c40] mb B I16..4: 0.5% 0.9% 0.0% B16..8: 24.4% 1.9% 0.3% direct: 1.6% skip:70.3% L0:40.7% L1:54.9% BI: 4.3%
[libx264 @ 0xc410c40] 8x8 transform intra:70.0% inter:83.8%
[libx264 @ 0xc410c40] coded y,uvDC,uvAC intra: 45.1% 49.5% 10.1% inter: 11.3% 13.0% 0.6%
[libx264 @ 0xc410c40] i16 v,h,dc,p: 32% 27% 6% 36%
[libx264 @ 0xc410c40] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 18% 29% 4% 5% 6% 5% 5% 5%
[libx264 @ 0xc410c40] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 18% 17% 5% 9% 8% 7% 5% 3%
[libx264 @ 0xc410c40] i8c dc,h,v,p: 59% 20% 18% 4%
[libx264 @ 0xc410c40] Weighted P-Frames: Y:15.9% UV:10.1%
[libx264 @ 0xc410c40] ref P L0: 60.2% 19.2% 15.5% 4.9% 0.3%
[libx264 @ 0xc410c40] ref B L0: 90.6% 8.4% 1.1%
[libx264 @ 0xc410c40] ref B L1: 97.7% 2.3%
[libx264 @ 0xc410c40] kb/s:3010.02

[Carl Eugen Hoyos]

From a users perspective this is a regression since f8d74cbd, simply reverting the change works fine (I will attach a patch that I originally created), I don't understand what it is supposed to do.
If the intended use-case is "Use the downmix instead of the original (5.1) sound" then it should only be used if out_ch_layout is mono or stereo and/or depending on a user option.

[Cigaes]

I confirm the downmixing is at fault, not the sample. It can be observed using the following command:
./tools/make_chlayout_test FL+FR+FC+LFE+BL+BR+DL+DR -ac 2 /tmp/2ch.wav
The resulting file says "front left, front right", but should be saying "downmix left, downmix right".

The commit you are pointing seems to be doing half the work: when converting to stereo from a layout that has DL+DR, the matrix should just map DL to FL and DR to FR and drop the rest. Instead, it maps FL and FR.

[Carl Eugen Hoyos]

Replying to Cigaes:

I confirm the downmixing is at fault, not the sample.

(Any doubts?)

It can be observed using the following command:
./tools/make_chlayout_test FL+FR+FC+LFE+BL+BR+DL+DR -ac 2 /tmp/2ch.wav
The resulting file says "front left, front right", but should be saying "downmix left, downmix right".

Thank you for pointing to make_chlayout_test (I haven't used it so far), I still have a slight preference for real-world samples.
But assuming make_chlayout_test calls swresample, I wonder if you are right:
$ ffmpeg -i 5.1plusdownmix.wav -ac 2 out.wav should definitely output FL+FR imo (not DL+DR).

The commit you are pointing seems to be doing half the work: when converting to stereo from a layout that has DL+DR, the matrix should just map DL to FL and DR to FR and drop the rest.

Imo, it should only do that if mono or stereo output was requested (and the user should be able to either force or forbid using DL+DR to output FL+FR or FC instead of 5.1).
The original commit was meant for DL+DR output, I still wonder what the exact use-case was. (Probably ffmpeg -i input -channel_layout DL+DR out.wav but I wonder if this is really useful.)

[Michael Niedermayer]

Fixed in c56d4dab039b352961cca298d753b04e2f2fd990