chopped audio output on certain RealAudio streams

[david.madore@…]

I'm afraid this bug isn't fully reproducible, so I'll give the most details I can.

In a nutshell: playing the stream (whose rtsp URL is contained in)
​http://www.bbc.co.uk/worldservice/ram/live_infent.rpm (typically
rtsp://rmlivev8.bbc.net.uk/farm/*/ev7/live24/worldservice/liveinfent.ra or
something similar) gives a chopped sound output after roughly 10 to 20 minutes.

("Chopped" is hard to describe: it seems as though there were two streams

playing intermittently, switching perhaps twice per second.)

I've reproduced this with several different versions of the RealAudio codec
(including the very latest), and the RealAudio player (10GOLD version
10.0.5.756) does not have the problem, so the codec is probably not in cause and
this must be an MPlayer bug.

Here are some details on my config: host is a Pentium IV at 3.4GHz running
Linux-2.6.12.4, MPlayer version is 1.0pre7 (but the bug has also been confirmed
on a more recent CVS snapshot, and also with older versions), Internet
connection is at roughly 6Mbit/s (this may play a role in some way - but it's
certainly fast enough to play in real time). Here is the MPlayer output:

vega david /tmp $ /opt/MPlayer/bin/mplayer -af volume=3:1 -cache 128
'rtsp://rmlivev8.bbc.net.uk/farm/*/ev7/live24/worldservice/liveinfent.ra'
MPlayer 1.0pre7-3.3.5 (C) 2000-2005 MPlayer Team
CPU: Intel Pentium 4/Xeon/Celeron Northwood (Family: 8, Stepping: 4)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

Playing rtsp://rmlivev8.bbc.net.uk/farm/*/ev7/live24/worldservice/liveinfent.ra.
Resolving rmlivev8.bbc.net.uk for AF_INET6...
Couldn't resolve name for AF_INET6: rmlivev8.bbc.net.uk
Resolving rmlivev8.bbc.net.uk for AF_INET...
Connecting to server rmlivev8.bbc.net.uk[212.58.224.93]:554 ...
Cache size set to 128 KBytes
Connected to server: rmlivev8.bbc.net.uk
Cache fill: 18.75% (24576 bytes) REAL file format detected.
Stream description: Audio Stream
Stream mimetype: audio/x-pn-multirate-realaudio-live
demux_real: invalid chunksize! (0)
Clip info:

name: World Service Information And Entertainment
author: BBC World Service
copyright: (C) British Broadcasting Corporation 2005

==========================================================================
Opening audio decoder: [realaud] RealAudio decoder
opening shared obj '/opt/MPlayer-1.0pre7/lib/codecs/cook.so'
Audio codec: [2] 16 Kbps Music - RealAudio
Audio bitrate: 16.193 kbit/s (2024 bps)
AUDIO: 22050 Hz, 1 ch, s16le, 16.2 kbit/4.59% (ratio: 2024->44100)
Selected audio codec: [ra10cook] afm:realaud (RealPlayer 10 COOK audio)
==========================================================================
Checking audio filter chain for 22050Hz/1ch/s16le -> 22050Hz/2ch/s16le...
AF_pre: 22050Hz/1ch/s16le
AO: [oss] 22050Hz 2ch s16le (2 bps)
Building audio filter chain for 22050Hz/1ch/s16le -> 22050Hz/2ch/s16le...
Video: no video
Starting playback...
A: 757.2 (12:37.1) 0.2% 18%
Exiting... (Quit)

(I quit some time after the output became chopped.)

I tried with -ao pcm and the output file was fine (no chopped output).

I have some evidence that the bug was noticed by other people: see
​http://forums.slimdevices.com/archive/index.php/t-11088.html (search for "chopped").

[david.madore@…]

Here's another information: I got a chopped stream using -dumpstream, it's at
<URL: ftp://quatramaran.ens.fr/pub/madore/tmp/bbc.ra > (it's chopped almost
right from the start, after maybe five seconds or so). Sadly, the original
RealPlayer refuses to play this stream at all, so it doesn't tell us much.

I suspect a bug in the RTSP/streaming layer of MPlayer.

[r_togni@…]

Unfortunalely it's a known problem: when there is some packet loss (a good way
to reproduce it is to use a heavily loaded server), MPlayer lost audio sync and
doesn't recover it.

My understanding of the problem it that it happens because of the descrambling
matrix: a number of audio packets are mixed in a data block, to minimize the
effect of data loss: if some bytes are missing the descrambling algorithm mixes
packets from current and previuos blocks, causing the "chopped" effect (packets
played out of order?)
If there is some reliable way to detect data loss at rtsp level, probably
flushing audio and setting the flag that makes demuxer wait for an audio
keyframe is enough to solve the problem (but i never tested it).

Can you check if you can reproduce it with xine? The streaming code is the same
as mplayer, while the realmedia demuxer is different.

[david.madore@…]

I just tried Xine, and, indeed, the same bug occurs (with xine-lib-1.1.0 +
xine-ui-0.99.4).

Maybe it's worth looking at RealPlayer10, since it does not seem to encounter
the problem: does their rtsp code come from the Helix (open source) part or is
it a closed source add-on?

Also I wonder why the decoder state is not occasionally reset by some kind of
key-frame (once the "chopped" effect starts, it seems to last forever).

[david.madore@…]

Indeed, there is an open source implementation of RTSP and RTP in Helix player,
and the code seems not too badly written (at least at a first glance), so it
might be worth having a look at, since it does not seem to have the problem
reported here.

Also, I'm not sure I understand the relation between RTSP and RTP, but according
to RFC 3550, RTP has a sequence number which is used to detect packet loss (or
duplication).

[gamester17@…]

This fix for garbled audio/sound RealAudio doesn't help does it?;
​http://mplayerhq.hu/pipermail/mplayer-dev-eng/2005-October/thread.html#37602
​http://mplayerhq.hu/pipermail/mplayer-dev-eng/2005-October/037602.html

[gamester17@…]

Adding search keywords (for people searching for RealMedia bugs/issues): Real,
RealNetworks RealPlayer, RealVideo, RealAudio, RM, RAM, RA, RV, RMVB, live,
live.com

[dev.null@…]

(In reply to comment #2)

Unfortunalely it's a known problem: when there is some packet loss (a good way
to reproduce it is to use a heavily loaded server), MPlayer lost audio sync and
doesn't recover it.

My understanding of the problem it that it happens because of the descrambling
matrix: a number of audio packets are mixed in a data block, to minimize the
effect of data loss: if some bytes are missing the descrambling algorithm mixes
packets from current and previuos blocks, causing the "chopped" effect (packets
played out of order?)
If there is some reliable way to detect data loss at rtsp level, probably
flushing audio and setting the flag that makes demuxer wait for an audio
keyframe is enough to solve the problem (but i never tested it).

Can you check if you can reproduce it with xine? The streaming code is the same
as mplayer, while the realmedia demuxer is different.

If it is the same issue I have a uploaded a sample ra file that reliably
demonstrates audio packet mixing at bug 435. As a local file, there is no
packet loss. The file may have been captured from a lossy stream maybe?

[r_togni@…]

No, it's different. the bug #435 is caused by lack of support for sipr codec in
old realaudio files.

[gamester17@…]

Has any fix/hack/patch been implemented for this into MPlayer's public CVS yet?

[r_togni@…]

Should be fixed