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

[Bryan Alton]

Reimar Döffinger wrote:

> Hi,
> On Tue, Oct 04, 2005 at 08:01:17AM +0100, Bryan Alton wrote:
>> As I haven't posted before to the dev list - I think they are considering
>> it carefully. I thought they would be quicker.
> 
> It usually takes very long, but I also have to say I did not yet see you
> patch on the developer list (maybe there are just too many patches and I
> missed it?).
> Also, did you investigate if it would be possible/what it would take to
> put this code at the stream layer? Since it basically deals with packet
> loss in theory this would be the more appropriate place.
> 
> Greetings,
> Reimar Döffinger

I sent the patch to the devel yesterday 3 Oct at 8:34. I also replied to 
the e-mail requesting confirmation as I hadn't posted before. I then got
another e-mail saying the post was being considered by the moderator.

At first I tried to put the patch into stream but as far as I could 
tell it was not possible to replace the missing packets with a duplicate
previous packet witha neat solution - the stream seems to only ever
have 1 packet and adding packets at stream level felt wrong.  

However at the time, I was becoming familiar with the problem, 
undocumented RealAudio and Mplayer and wanted a small patch that
would break other aspects. 

There may be another solution with some guidance.

Now I understand the way how the version of RealAudio used by the
BBC works and I think Mplayer doesn't handle it well and can lose
sync easily as it doesn't make full use of the keyframe flag.  The
proper way of handling the RealAudio would have been to buffer all
the packets starting with a keyframe until another keyframe is 
found (usually 8 or 16).  Then determine if there are any missing
packets, fill in the missing packets and then release the packets
to the stream levels and start processing the next keyframe. This
would require a significant rewrite of code which I felt would
break other aspects of Real support so the end result would be
technically better but functionally worse.

regards

Bryan