GNOME Bugzilla – Bug 331588
[rmdemux] realmedia files with AC3 don't work
Last modified: 2006-03-24 19:09:35 UTC
sample files from: http://www.karinegeorgian.com/av.htm I ve tried gst-launch-0.10 filesrc location=martinu.rm ! rmdemux ! a52dec ! audioconvert ! alsasink and gst-launch-0.10 playbin -v uri=file:///home/edlima/Projects/testFiles/martinu.rm both play no sound and dont show error msgs: the output follows below: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... No accelerated IMDCT transform found Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock2 Trying the same file with mplayer it works fine, the output follows below: Playing martinu.rm. REAL file format detected. Stream description: The Audio Stream Stream mimetype: audio/x-pn-realaudio Clip info: name: Martinu - Rossini Variations author: Karine Georgian copyright: �2000 comment: RealEncoder 5.1.0.32 Win95 4.0 1212 Pentium MMX 1 Live = 0 ac = 32 Kbps Music Mono abw = 32.0 asi = 22050 abi = 16 abo = 16 ach = 1 ========================================================================== Opening audio decoder: [liba52] AC3 decoding with liba52 Using SSE optimized IMDCT transform AC3: 1.0 (mono) 16000 Hz 32.0 kbit/s Using MMX optimized resampler AUDIO: 16000 Hz, 2 ch, s16le, 32.0 kbit/6.25% (ratio: 4000->64000) Selected audio codec: [a52] afm:liba52 (AC3-liba52) ========================================================================== Checking audio filter chain for 16000Hz/2ch/s16le -> 16000Hz/2ch/s16le... AF_pre: 16000Hz/2ch/s16le AO: [oss] 16000Hz 2ch s16le (2 bps) Building audio filter chain for 16000Hz/2ch/s16le -> 16000Hz/2ch/s16le... Video: no video Starting playback... A: 1.3 (01.2) 0.1%
Looks like it might be an a52dec problem: tim@sceptic:~/samples/audio/realaudio$ gst-launch-0.10 file:///home/tim/samples/audio/realaudio/martinu.rm ! rmdemux ! a52dec ! fakesink -v 2>&1 | grep -e timestamp -e segment -e eos event ******* E (type: 102, GstEventNewsegment, update=(boolean)false, rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, start=(gint64)0, stop=(gint64)-1, position=(gint64)0) event ******* E (type: 102, GstEventNewsegment, update=(boolean)false, rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, start=(gint64)0, stop=(gint64)-1, position=(gint64)0) chain ******* < ( 4096 bytes, timestamp: 0:00:55.097219954, duration: 0:00:00.011609977 chain ******* < ( 4096 bytes, timestamp: 0:00:55.132049885, duration: 0:00:00.011609977 chain ******* < ( 4096 bytes, timestamp: 0:02:23.609000000, duration: 0:00:00.016000000 chain ******* < ( 4096 bytes, timestamp: 0:02:23.625000000, duration: 0:00:00.016000000 event ******* E (type: 86, EOS) The buffers coming from rmdemux are continuously timestamped. Also noteworthy might be that a52dec keeps posting/sending new taglists with different bitrates all the time (~10 times altogether).
The debug log has a chunk like this for about every single buffer the chain function receives ... a52dec(20888) gsta52dec.c(588):gst_a52dec_chain_raw:<a52dec0> Received buffer with ts 0:01:01.013000000 a52dec(20888) gsta52dec.c(627):gst_a52dec_chain_raw: No sync found
The following is based on some testing with fluendo's AC3 decoder, but it should be applicable to a52dec as well. The data that comes out of the demuxer is clearly not raw AC3. If you byteswap it (2 bytes at a time) it looks like AC3 frames superficially - it contains the AC3 syncwords, and validates both AC3 CRCs (though it seems to skip something about the length of an AC3 frame in between each AC3 frame that it actually reads successfully - so maybe it's only getting half the data anyway). However, then, the AC3 frames have BSI > 8 (this is essentially the stream version - being > 8 indicates that it's an incompatible future version not covered by the AC3 specification). If anyone wants to try doing the byteswapping trick with a52dec, maybe it understands this bitstream revision?
Seems to work fine with a52dec if the content is byteswapped. The byteswapping seems to be standard procedure. 2006-03-24 Tim-Philipp Müller <tim at centricular dot net> * gst/realmedia/rmdemux.c: (gst_rmdemux_add_stream), (gst_rmdemux_fill_audio_packet), (gst_rmdemux_parse_packet): Extra data usually goes into the caps as 'codec_data', not as first buffer into the stream. Need to byte swap AC3 content in realmedia files for some reason (fixes #331588).