[MPlayer-users] Re: BUG - Garbled output playing realaudio

[Bryan Alton]

Neil Sleightholm wrote:

> Bryan
> 
> Is there anything to be agained from seeing what RealPlayer does? I
> just recorded an Ethereal trace during the Radio 4's Archers broadcast
> and didn't hear any errors. The trace doesn't really mean much to me
> but Ethereal did highlight a few packet errors.
> 
> Neil

I started looking at this problem by having RealPlayer and Mplayer playing
simultaneously and looking at the datastreams on Ethereal.  That is how
I first twigged that the problem was dropped packets.

The trouble with streaming data is that beyond basic TCP there is no error
handling visible at a TCP/IP level.  RealAudio uses the RTSP/RDT protocol 
(a simple description can be found in Tanenbaum) and then stripes the
data across many packets so that if one or two packets are lost, the player
can fill in the loss from other data packets. Error detection but no retransmission
is the philosophy as there is no time to retransmit errors.  The current
problem is that the packets are dropped before the TCP data transmission stage.

The packets the BBC are sending are 640 bytes long made up of 5 128 byte
sound samples. But it takes 16 packets to make up a continuous bit
stream to go into the codec - keyframe make the start of each block.
If one of these 640 byte packets is lost, then 5 gaps of 23ms duration
need to be filled spread across approx. 1.84 seconds.  If the right
adjacent sample is chosen to replace the missing packet most people
won't detect the 23ms gaps. Only when you get a loss of 4 or 5 packets
will the gaps become noticable.

If Ethereal is run on the machine which is doing the communication, it
will show CRC packet errors if the CRC is calculated by your network
interface card/chip which is usually the case these days.  You
need to run Ethereal on a separate machine from the source/destination 
to be sure of detecting real CRC packets errors.

Bryan.