GNOME Bugzilla – Bug 348002
AC3 5.1 foreground movie sound cannot be heard in Totem/gst-launch while OK in MPlayer
Last modified: 2006-09-26 19:21:36 UTC
It's the second movie that I've come across that exhibits this problem. I started Totem and the background music started playing but when the people started talking there was nothing coming out of their mouths to hear (and I had my sound volume set pretty high). I tried playing the movie through "gst-launch-0.10 playbin uri=file:///home/lubo/foo.avi" and the results were the same. So I ran "mplayer foo.avi" and everything (i.e. the foreground sound/speech) came out right. $ mplayer foo.avi MPlayer dev-SVN-r19100-4.1.1 (C) 2000-2006 MPlayer Team CPU: Intel(R) Celeron(R) CPU 2.60GHz (Family: 15, Model: 2, Stepping: 9) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 Playing /home/lubo/foo.avi. AVI file format detected. VIDEO: [XVID] 576x240 24bpp 23.976 fps 963.0 kbps (117.6 kbyte/s) Clip info: Software: Nandub v1.0rc2 Xlib: extension "XFree86-VidModeExtension" missing on display "localhost:1.0". ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) ========================================================================== ========================================================================== Opening audio decoder: [liba52] AC3 decoding with liba52 Using SSE optimized IMDCT transform AC3: 5.1 (3f+2r+lfe) 48000 Hz 448.0 kbit/s Using MMX optimized resampler AUDIO: 48000 Hz, 2 ch, s16le, 448.0 kbit/29.17% (ratio: 56000->192000) Selected audio codec: [a52] afm: liba52 (AC3-liba52) ========================================================================== AO: [oss] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... I wasn't much into gstreamer and gst-launch so I went trying and randomly combining things from the man pages. I got the same problem with no foreground sound/speech with the following: $ gst-launch-0.10 filesrc location="/home/lubo/foo.avi" ! avidemux ! a52dec ! audioconvert ! audioresample ! autoaudiosink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock2 But when I changed the command line to the following, then the sound came out right just like in MPlayer: $ gst-launch-0.10 filesrc location="/home/lubo/share/movies/Pirates of the Carribean/Pirates of the Carribean (1).avi" ! avidemux ! a52dec ! audioconvert ! audioresample ! audio/x-raw-int,rate=48000,channels=2 ! autoaudiosink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock2 I suppose this means that what I'm reporting is not actually a bug in a52dec/gst-plugins-ugly/gstreamer but I thought that because MPlayer detected it and I couldn't tweak Totem to play it out right, it might be something that a52dec couldn't figure out (or some part of gstreamer for that matter but I'm not very educated in the area). Thank you in advance for your attention.
I get this as well with DVDs, not sure what the problem is yet.
The thing is that mplayer uses liba52 channel downmixing which use conversion hinting from the a52 headers. On the other hand, totem does downmixing by audioconvert plugin which use static conversion matrix (which does not fit for every situation). I have commited patch in bug #350761 that enables downmixing directly in a52dec. But I do not know if the Totem pipeline will choose to downmix in a52dec or audioconvert plugin (but I think that audioconvert should chose passthrough mode if it can).
This should be fixed now that #350761 has been committed. That'll be in the next release of gst-plugins-ugly.
I'm sorry about the late confirmation as the reporter of this bug that CVS HEAD indeed fixes the problem. Thank you, guys, for the excellent work and for making gstreamer rock! You've made my day once more.
*** Bug 357853 has been marked as a duplicate of this bug. ***