GNOME Bugzilla – Bug 731038
playbin downmixes 5.0 multichannel-audio to stereo
Last modified: 2014-11-12 14:26:47 UTC
when playbin gets the uri of a file containing audio with 5.0 channels (FRONT_LEFT,FRONT_RIGHT,FRONT_CENTER,REAR_LEFT,REAR_RIGHT) it gives following warning: **(python3:13745): WARNING **: Unpositioned audio channel position flag set but channel positions present and plays the file downmixed to stereo. 5.1 gives the same warning but plays properly same behaviour using gst-play-1.0 the above did not happend using gstreamer 0.1 components gst123 played properly the handmade pipeline below plays properly to gst-launch-1.0 -v filesrc location=testchannels50.flac ! flacparse ! flacdec ! audioconvert ! audio/x-raw, channels=6 ! alsasink please restore the behaviour of the 0.1 version, because 5.0 is the MOST common case in classical-music media (LFE is mostly unwanted here) . Nearly all comercial classical concertvideos and buyable audio-files have the above channellayout. So it would be convenient for users of playbin, that the warning may remain, but the most common channel-layout for 5.0 is set as default in the same manner as you do it for 5.1
http://www.theclassicalshop.org.uk/samples/Chandos_Surround_5_0_test_file.flac
I get 404 not found for that file. Could you attach a compressed (xz -9) debug log made with GST_DEBUG=*:6 for the old 0.10 case and gst-play-1.0 ? The first second or so should be enough, we just need the preroll/negotiation steps.
new link for the testfile https://comcenter.netcologne.de/publications/documents/29683/2522ce8f400e60b22e3bd3c8efeb7c53
Created attachment 277675 [details] logs of 0.1 and 1.0 gst-launch playbin playing 5.0 channels testfile
attached requested logfiles Note: the 0.10 testrun lacks sound with --gst-debug=*:6, while 1.0 plays sound whith the same option but i can confirm that 0.10 without --gst-debug=*:6 played fine. confirmation based on my ears and the display of my av-receiver. testcases on different machines, but with the same sound-configuration: pure alsa with .asoundrc pointing to hdmi pcm.!default { type hw card 0 device 8 } ctl.!default { type hw card 0 device 8 }
Created attachment 277864 [details] [review] set the channel positions using the appropriate API If you can build gstreamer, can you test this patch and see if channels are played in the right speakers ?
Or if you don't know or can't build, let us know, please.
Comment on attachment 277864 [details] [review] set the channel positions using the appropriate API Looks good to me, should also check the other audio decoders for the same mistake. Will you do that Vincent? Not sure if we shouldn't reorder the channels to valid order before set_format() though...
I can go double check, yes.
faad and dvdlpcm set channel positions manually after passing NULL, but both do unset the unpositioned flag where appropriate. I'll make patches for those to pass channel positions directly.
Created attachment 278025 [details] [review] similar for faad
Created attachment 278026 [details] [review] similar for dvdlpcmdec
Testing the faad one, I had to set call gst_audio_channel_positions_to_valid_order before setting, as the order was not valid on my sample. flacdec and dvdlpcmdec use const tables, so I think they're already in the correct order. I don't have a sample to test dvdlpcmdec. I also have only stereo output. Do we assume the original bug is fixed by this, without hearing the result ?
The "valid" order is the GStreamer order, which might be different from the FLAC or DVD LPCM order. So better reorder before in all cases :)
Comment on attachment 278025 [details] [review] similar for faad And here you reorder first but don't keep the original order around... which we will need a few lines later to generate the reorder map
Is here a reason why this reordering could not be done in gst_audio_info_set_format ?
Yes, making sure that the order is not magically transformed to GStreamer order under the hood and then people are confused that they hear the left channel on the right side :)
Ah, so the mapping isn't automatic. Fair enough.
Created attachment 278137 [details] [review] flacparse: set ordered chanel positions
Created attachment 278138 [details] [review] faad: set ordered chanel positions
Created attachment 278139 [details] [review] dvdlpcmdec: set ordered chanel positions
This code is confusing me a bit, but I think this is correct. The FLAC sample plays fine (at least when mapped to stereo). 6 channel AAC plays fine though I've no idea if the channels are in the right place, and I have no dvdlpcm sample.
commit 0b36fe59e1725ffa2905b3aac5f424b1299791c6 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Wed Jun 4 12:11:10 2014 +0100 flacdec: set the channel positions using the appropriate API This avoids _set_format setting the unpositioned flag when passed NULL as channel positions, as it would not be cleared when setting actual channel positions later. commit cf9c73367d65887c573a803ec5817082758637f7 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Jun 6 13:57:30 2014 +0100 faad: set channel positions using the appropriate API https://bugzilla.gnome.org/show_bug.cgi?id=731038 commit 86562f56e208d0d7360a9b5f7bc5cf13836f06a3 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Jun 6 13:59:57 2014 +0100 dvdlpcmdec: set channel positions using the appropriate API https://bugzilla.gnome.org/show_bug.cgi?id=731038 I'll pick -good to file this bug since it spans -good, -bad, and -ugly.