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

[Bryan Alton]

Neil Sleightholm wrote:

I done a few more tests and the following are my conclusions.

1. The Mplayer "collapses" I have seen is a red herring. It results from
moving a window in Linux if you hold the mouse button down for more than a
few seconds.  In Windows when Mplayer is in a C:> prompt window if you
scroll back up and hold it for a few seconds.  I think MPlayer output is
frozen and this backlogs the whole Mplayer as it seems to be single
threaded. It never recovers - audio delay % just gets higher.

2. However, after one of the "collapses" Mplayer played choppy audio as you
described so that issues still has to be addressed. However if my point 1
is true then the chances of choppy audio will be reduced when Mplayer is in
"really-quiet" mode which is how it will work within AlienBBC.

3. I found a vestigial resync audio function which I have used to resync at
the start of every keyframe and this should get Mplayer back in sync quite
quickly if it does get into trouble. It seems to work but it needs more 
testing. I shall post a patch in a few days - although I don't know if the
moderators will like it.

4. I have seen an occasion with a time gap about the same as reported - 1740
is in fact 15 times 116 which means 15 of the 16 packets in that block were
lost.  My code would generate missing packets from the old data stream so
the user will hear an extended sound as I only use two samples but it
should remain in sync.   However a gap above  1856ms will cause problems as
the keyframe currently is not used - that is what the patch in point 3 will
address.

Regarding distribution an Mplayer binary ideally to get a wider test
audience, according to the Mplayer documentation (link below) there is no
longer a copyright issue. 

http://mplayerhq.hu/DOCS/HTML/en/mplayer-binary.html

Bryan