GNOME Bugzilla – Bug 658546
ac3parse: RealAudio file with AC-3 audio no longer plays
Last modified: 2011-12-20 19:37:02 UTC
The file below no longer plays, because ac3parse doesn't accept the bsid of 10. According to http://matroska.org/technical/specs/codecid/index.html BSID 9/10 are basically like normal AC-3 but for lower samplerates. +++ This bug was initially created as a clone of Bug #599676 +++ Description of the problem: Back in Ubuntu 8.04 gstreamer was able to play a particular RealAudio file but with 9.10 this file seems to just hang. Steps to reproduce: 1. Run wget http://wso.williams.edu/~aeatonsa/bomb/audio/real/Track13.ra gst-launch-0.10 filesrc location=Track14.ra ! decodebin ! audioconvert ! audioresample ! pulsesink . Expected results: Remixed version of the classic Bomberman battle music scale to be played. Actual results: The following is printed: Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock but no music is produced. How reproducible is the problem? It is reproducible every time. Additional information: The file plays in the gstreamer bundled with Ubuntu 8.04. Version Information: gstreamer0.10-alsa 0.10.25-2ubuntu1 gstreamer0.10-ffmpeg 0.10.9-1 gstreamer0.10-nice 0.0.9-2 gstreamer0.10-plugins-bad 0.10.14-4ubuntu1 gstreamer0.10-plugins-base 0.10.25-2ubuntu1 gstreamer0.10-plugins-base-apps 0.10.25-2ubuntu1 gstreamer0.10-plugins-good 0.10.16-1ubuntu3 gstreamer0.10-plugins-ugly 0.10.12-1 gstreamer0.10-pulseaudio 0.10.16-1ubuntu3 gstreamer0.10-tools 0.10.25-2 gstreamer0.10-x 0.10.25-2ubuntu1
That link says 9 and 10 have bitstream changes that break compatibility with decoders than can do <= 8 though. Merely allowing 9 and 10 might mean we let those streams through only for them to fail to decode. Which is better, I guess. I'll see if I can find a spec for that.
I was thinking that decoders that don't support those streams could just signal that by limiting the sample rates they accept as input.
Well, the spec says, roughly: <= 8 is normal AC3 11 to 16 is EAC3. It says nothing about 9 and 10 AFAICT. ffmpeg seems to consider <= 10 as AC3. So if the attached file was indeed working before, it may be best to just accept 9 and 10, as normal AC3. It certainly works with that file.
Created attachment 196085 [details] [review] ac3parse: let bsid 9 and 10 through Files with 9 and 10 happen, and seem to comply with the <= 8 format, so let them through. The spec says nothing about 9 and 10.
Comment on attachment 196085 [details] [review] ac3parse: let bsid 9 and 10 through I think we need to do something about the sample rates as well (otherwise I'd just have fixed it myself immediately instead of filing a bug ;))
Heh, sorry. The spec seems to say the format change happens with 11-16. So just the sample rate seems different.
Created attachment 196094 [details] [review] ac3parse: use bsid 9 and 10 to control sample rate See http://matroska.org/technical/specs/codecid/index.html The spec is silent about this though...
commit d17d13219c3293e0eb586ef54cb43187060dca92 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Sep 9 12:35:50 2011 +0100 ac3parse: use bsid 9 and 10 to control sample rate See http://matroska.org/technical/specs/codecid/index.html The spec is silent about this though... https://bugzilla.gnome.org/show_bug.cgi?id=658546
*** Bug 666602 has been marked as a duplicate of this bug. ***
Review comments were addressed by the second patch and this slipped through the net, pushing now, it actually fixes playback of the test case. commit 93ac6fb47ed70039e9700e6c73770afa10b9cd31 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Sep 9 11:42:09 2011 +0100 ac3parse: let bsid 9 and 10 through Files with 9 and 10 happen, and seem to comply with the <= 8 format, so let them through. The spec says nothing about 9 and 10. https://bugzilla.gnome.org/show_bug.cgi?id=658546