Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#1149 closed defect (worksforme)

wrong channels / poor playback for 7 channel dts

Reported by: fro Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: dca 6.1
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

There's already a sample file (not uploaded by me) available here:

http://samples.mplayerhq.hu/A-codecs/DTS/lotr_5.1_768.dts

This file plays fine for me in mplayer, but with ffplay I can't get this file to play correctly at all (using ffmpeg 0.10.2). Also, when converting it to FLAC / OGG / etc with ffmpeg, mplayer sounds just as bad as ffplay when using it on the converted file.

mplayer on the dts gives me birds chirping (about centered) and the sound of running water; at 0m35s there's also voice. It sounds good with mplayer. With ffplay, the birds chirp on the left side only, the water is almost not audible, and the voice is hidden far in the background.

So I think ffmpeg is somehow using the wrong channels for this file.

I used the pan filter to randomly switch some channels when downmixing to stereo (stupid script attached, couldn't get pan to work with FC/FL/FR names though), which helps - but then I don't really know what I switched and I haven't found the "correct" setting anyway (assuming that what mplayer does is correct - I don't know, but it sounds good to me).

The whole channel mapping thing is unfathomable for me; hopefully someone more experienced can take a look.

$ ffplay lotr_5.1_768.dts 
ffplay version 0.10.2 Copyright (c) 2003-2012 the FFmpeg developers
  built on Mar 28 2012 23:57:36 with gcc 4.5.3
  configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-march=native -O2 -pipe' --extra-cflags='-march=native -O2 -pipe' --extra-cxxflags='-march=native -O2 -pipe' --disable-static --enable-gpl --enable-version3 --enable-postproc --enable-avfilter --disable-stripping --disable-debug --disable-doc --disable-network --disable-vdpau --enable-gnutls --enable-libmp3lame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-libdc1394 --enable-openal --disable-indev=v4l --disable-indev=v4l2 --disable-indev=jack --enable-x11grab --enable-libfreetype --enable-pthreads --enable-libopencore-amrwb --enable-libopencore-amrnb --enable-libmodplug --enable-libspeex --disable-amd3dnow --disable-amd3dnowext --disable-altivec --disable-avx --disable-vis --disable-neon --cpu=host --enable-hardcoded-tab  libavutil      51. 35.100 / 51. 35.100
  libavcodec     53. 61.100 / 53. 61.100
  libavformat    53. 32.100 / 53. 32.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 61.100 /  2. 61.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0.  6.100 /  0.  6.100
  libpostproc    52.  0.100 / 52.  0.100
[dts @ 0xd77c60] max_analyze_duration 5000000 reached at 5002667
[dts @ 0xd77c60] Estimating duration from bitrate, this may be inaccurate
Input #0, dts, from 'lotr_5.1_768.dts':
  Duration: 00:02:05.18, start: 0.000000, bitrate: 768 kb/s
    Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, 7 channels (FL+FR+FC+LFE+BC+SL+SR), s16, 768 kb/s

#!/bin/bash

unique="`echo -e "0\n1\n2\n3\n4\n5\n6" | sort`"

for FL in {0..6}
do
    for FC in {0..6}
    do
        for BL in {0..6}
        do
            for SL in {0..6}
            do
                for FR in {0..6}
                do
                    for BR in {0..6}
                    do
                        for SR in {0..6}
                        do
                            [ "$unique" != "`echo -e "$FL\n$FC\n$BL\n$SL\n$FR\n$BR\n$SR" | sort`" ] && continue

			    echo -e "FL=$FL\nFC=$FC\nBL=$BL\nSL=$SL\nFR=$FR\nBR=$BR\nSR=$SR\n"

                            ffplay -f lavfi -i "amovie=lotr_5.1_768.dts [l]; [l] pan=stereo:c0=c$FL+0.5*c$FC+0.6*c$BL+0.6*c$SL:c1=c$FR+0.5*c$FC+0.6*c$BR+0.6*c$SR"
                        done
                    done
                done
            done
        done
    done
done

Change History (11)

comment:1 by Carl Eugen Hoyos, 12 years ago

(I don't think ffplay is supposed in any way to play 7-channel samples correctly.)

Please test ffmpeg -i lotr_5.1_768.dts out.wav and report how the resulting file plays with MPlayer / WMP, providing complete, uncut console output.

comment:2 by fro, 12 years ago

$ ffmpeg -i lotr_5.1_768.dts out.wav 
ffmpeg version 0.10.2 Copyright (c) 2000-2012 the FFmpeg developers
  built on Mar 28 2012 23:57:36 with gcc 4.5.3
  configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --cxx=x86_64-pc-linux-gnu-g++ --ar=x86_64-pc-linux-gnu-ar --optflags='-march=native -O2 -pipe' --extra-cflags='-march=native -O2 -pipe' --extra-cxxflags='-march=native -O2 -pipe' --disable-static --enable-gpl --enable-version3 --enable-postproc --enable-avfilter --disable-stripping --disable-debug --disable-doc --disable-network --disable-vdpau --enable-gnutls --enable-libmp3lame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-libdc1394 --enable-openal --disable-indev=v4l --disable-indev=v4l2 --disable-indev=jack --enable-x11grab --enable-libfreetype --enable-pthreads --enable-libopencore-amrwb --enable-libopencore-amrnb --enable-libmodplug --enable-libspeex --disable-amd3dnow --disable-amd3dnowext --disable-altivec --disable-avx --disable-vis --disable-neon --cpu=host --enable-hardcoded-tab  libavutil      51. 35.100 / 51. 35.100
  libavcodec     53. 61.100 / 53. 61.100
  libavformat    53. 32.100 / 53. 32.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 61.100 /  2. 61.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0.  6.100 /  0.  6.100
  libpostproc    52.  0.100 / 52.  0.100
[dts @ 0xe2d380] max_analyze_duration 5000000 reached at 5002667
[dts @ 0xe2d380] Estimating duration from bitrate, this may be inaccurate
Input #0, dts, from 'lotr_5.1_768.dts':
  Duration: 00:02:05.18, start: 0.000000, bitrate: 768 kb/s
    Stream #0:0: Audio: dts (DTS-ES), 48000 Hz, 7 channels (FL+FR+FC+LFE+BC+SL+SR), s16, 768 kb/s
Output #0, wav, to 'out.wav':
  Metadata:
    encoder         : Lavf53.32.100
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 7 channels (FL+FR+FC+LFE+BC+SL+SR), s16, 5376 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (dca -> pcm_s16le)
Press [q] to stop, [?] for help
size=   83622kB time=00:02:07.42 bitrate=5376.0kbits/s    
video:0kB audio:83622kB global headers:0kB muxing overhead 0.000079%

mplayer sounds good for lotr_5.1_768.dts
ffplay sounds bad for lotr_5.1_768.dts and out.wav. (completely identical as far as I can tell)
mplayer sounds bad for out.wav, but it's slightly different from ffplay. (I can tell the difference only when listening very closely)

good = sound seems to be centered / balanced, bad = sounds seems to be left-sided / backgrounded.

comment:3 by Carl Eugen Hoyos, 12 years ago

Keywords: dts 6.1 added
Resolution: worksforme
Status: newclosed
Version: unspecifiedgit-master

Did you test the wav file with WMP?

I don't think there is a problem with libavcodec and ffmpeg (for this sample), there is either a problem with ffplay or SDL, I am closing this ticket since the SDL documentation - http://www.libsdl.org/docs/html/sdlaudiospec.html - repeatedly mentions "mono or stereo", so I don't think SDL supports seven (or eight) channels. Please reopen the ticket if you believe I am wrong. (Since SDL has many more problems I think the long term solution is to move away from SDL to make FFplay a real playback software, imo it currently is more a testing tool.)

To reproduce the "good" behaviour that you get with MPlayer (which defaults to stereo) with FFplay, please run
$ ffplay -request_channels 2 lotr_5.1_768.dts
To reproduce the "bad" behaviour of FFplay with MPlayer (at least with some ao's), run
$ mplayer -channels 7 lotr_5.1_768.dts

The wav file produced with ffmpeg -i lotr_5.1_768.dts out.wav plays fine with WMP (and is read correctly by FFmpeg.)

The following commands also work fine here:
$ mplayer lotr_5.1_768.dts -channels 6
$ ffmpeg -request_channels 6 -i lotr_5.1_768.dts out.wav

comment:4 by fro, 12 years ago

Did you test the wav file with WMP?

I don't have WMP available right now, sorry.

$ ffplay -request_channels 2 lotr_5.1_768.dts

Thanks for the hint.

ffplay -request_channels 2 lotr_5.1_768.dts sounds good.
ffplay -request_channels 2 out.wav sounds bad.

I still can't get "good" output with any (Linux) player once ffmpeg processed it into any other format. This still smells like a bug to me but it's your software. :)

comment:5 by reimar, 12 years ago

ffplay -request_channels 2 out.wav sounds bad.

-request_channels 2 has no effect on raw PCM. You'd have to specify downsampling manually.
As Carl said you need to use -request_channels when converting to wav already.

I still can't get "good" output with any (Linux) player once ffmpeg processed it into any other format.

That doesn't have anything to do with processing it into any other format but with processing it into a 7-channel format that will always end up as such in the play.
7-channel audio seems to be broken in the sound system. PulseAudio (-ao pulse in MPlayer) right-out refuses to play such content at all, ALSA (-ao alsa) seems to play it but with different channel order (no idea whether it is MPlayer's or ALSA's fault).

comment:6 by reimar, 12 years ago

Oh:

[AO_ALSA] 7 channels are not supported.

So since ALSA can't play 7-channel audio that probably explains why no Linux player can play it.

comment:7 by fro, 12 years ago

The sound system should not be involved as it always sees the same thing (stereo).

The player being what reduces whatever channel layout of the source to stereo. (as I understand it)

ffmpeg is capable of converting multi-channel dts to multi-channel flac/ogg/wav and it should sound the same (esp. for the supposedly loss less formats) but that does not actually work. It still sounds to me like all channels are there somehow after the conversion, but just used in the wrong order.

in reply to:  7 comment:8 by Cigaes, 12 years ago

Replying to fro:

The sound system should not be involved as it always sees the same thing (stereo).

That is not true: the sound system sees what the player gives it.

The player being what reduces whatever channel layout of the source to stereo. (as I understand it)

Depends on the player design. In MPlayer, the design is to try to output the number of channels specified by the -channels option, defaulting to 2, using builtin codec capabilities if possible (it is possible with DTS) and manual downmixing if not.

In ffplay, the design is to output the data as decoded by the codec, and by default it request for the maximum number of channels. The latter point can be adjusted with -request_channels, but it only works for codecs that support it; PCM, obviously, can not.

ffmpeg is capable of converting multi-channel dts to multi-channel flac/ogg/wav and it should sound the same (esp. for the supposedly loss less formats) but that does not actually work. It still sounds to me like all channels are there somehow after the conversion, but just used in the wrong order.

The order is indeed wrong. The reason for that has already been given: SDL does not support 7 channels, while it supports 2 channels and 6 channels.

Here is a pointer to the relevant snippet of source code of SDL:
http://hg.libsdl.org/SDL/file/6bb657898f55/src/audio/alsa/SDL_alsa_audio.c#l271

Adding a workaround in ffplay would technically be possible, but it would conflict with a possible future implementation in SDL itself. For now, best to consider that complex channel layouts are not supported by ffplay.

Note that the internal rematrixing code in libswresample correctly handles 6.1 to stereo conversion.

in reply to:  7 comment:9 by Carl Eugen Hoyos, 12 years ago

Replying to fro:

ffmpeg is capable of converting multi-channel dts to multi-channel flac/ogg/wav and it should sound the same (esp. for the supposedly loss less formats) but that does not actually work.

I believe I showed already that it works fine for wav (or don't you agree that WMP is the relevant testing application for wav?), it works fine for libvorbis (in case that is what you mean with "ogg"), and it cannot work for flac, because no channel layout is defined for 7-channel flac: http://flac.sourceforge.net/format.html (look for "channel order")
But note that the following works as expected:

$ ffmpeg -i lotr_5.1_768.dts out.flac
$ ffmpeg -channel_layout 0x70f -i out.flac out.wav

in reply to:  6 comment:10 by Carl Eugen Hoyos, 12 years ago

Replying to reimar:

Oh:

[AO_ALSA] 7 channels are not supported.

So since ALSA can't play 7-channel audio that probably explains why no Linux player can play it.

This might be a relevant link:
http://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.html#_3_5_7_channel_support

comment:11 by Carl Eugen Hoyos, 11 years ago

Keywords: dca added; dts removed
Note: See TracTickets for help on using tickets.