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

[Bryan Alton]

Mark Bennett <mplayer <at> markandliz.co.uk> writes:

> 
> Neil Sleightholm <neil <at> x2systems.com> writes:
> 
> > 
> > RC wrote:
> > 
> > > No need to appologize, you've been quite patient, and it looks like
> > > I'm the only one looking at this problem...  I've reproduced it, but
> > > it's a bit difficult to track down because of a couple problems.  
> > > 
> > > For one thing, the last couple times I've tried playing from the URL
> > > you gave, I got nothing but silence, so it seems to be offline.  If
> > > you've got a few other URLs, that would help.
> > > 
> > > The other problem is that -ac racookwin is crashing, on my system at
> > > least.  I'll file a bugreport about that issue, and perhaps it will
> > > get fixed sometime soon.
> > > 
> > > So, for now, I can't even say if it's a codec or a network issue.  The
> > > fact that the codec doesn't report any problems seems suspicious, but
> > > I can't use the other 'cook' codec to see if anything changes.
> > 
> > Has anyone had any luck tracking down this bug?
> > 
> > Neil
> > 
> 
> I'm seeing exactly the same problem as Neil on BBC streams, and it's
> very annoying. If there is anything I can do to help track down the
> problem let me know, but I'm not a coder.......
> 
> Thanks in advance,
> Mark.
> 

I posted the following as a separate post whereas it should be have been here -
sorry.

I think I know what is causing the garbled audio problem.  The realaudio server
is dropping packets but only indicates it by jumps in the Data packet timestamps
and  setting the KeyFrame bit in the Flags. If you look at the timestamps of the
Real data Packet Headers (using ethereal) you will see that whereas normally the
time delta is about 116 - occassionally there are deltas of about 232 or 348. At
the same time, the keyframe flag which is normally set once every 32 packet, is
set at the right point to restart the striping. The striping mechanism is
explained in a doc in the Mplayer directory.

The Realaudio stream has the audio striped across multiple packets and so if
Mplayer doesn't detect the missing packets it starts putting the audio stream
back toegther in the wrng order. 

As implemented RTS just takes each packet and  buffers the data and ignore the
timestamp and key frame data.  What needs to be done is when a gap is detected,
some packets needs to be inserted to make up the loss.

I am trying to code up a solution but I think I am on the right track.  Can
anybody confirm my theory from their captured datastreams.