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

Bryan Alton balton at eircom.net
Wed Oct 5 23:54:56 CEST 2005


Neil Sleightholm wrote:

> I'm glad you are looking at this as it sounds quite complicated!
Yes and no - there are number of separate simple mechanisms which are
layered - the trouble is finding out which layer is at fault and sometimes
faults at a lower layer manifest themselves higher up - which is our choppy
audio problem.
> 
> I have just heard from someone else who is using this patch and he also
> noticed garbled out after many hours of use. He also said that he had
> had RealPlayer stop working while playing a live BBC stream.
RealPlayer was developed solely to work with a small family of audio streams
and only output to a display unlike Mplayer which has many different pieces
from different sources being made to work together. The piece of code
(demux_real) was reverse  engineered and it really doesn't implement the
protocol well. RealPlayer expected errors and has mechanisms to recover.
Mplayer doesn't expect errors in RealAudio data as it was probably written
to decode RA files and not streams and has no recovery mechanisms.
 
> If the stream got to a state where by your code couldn't recover, would
> it be possible to restart the streaming? (This probably shows my
> ignorance of how mplayer works.)

My code only detects the missing packets and fills in the gaps. As packets
are sent, regularly a packet has a flag set called the keyframe flag and
this is used by RealPlayer to find a suitable start point to restart the
streaming afresh. Mplayer does nothing with this flag. To restart streaming
I'd have to find a way to use this flag without rewriting a whole load of
code.

That said I haven't had Mplayer breakdown - todays trace shows a valid
stream but my initial guess is Mplayer broke down because it's buffer was
empty - if that is the case the question is how to instruct Mplayer to wait
a while after a problem.  The other question is how much effort to put into
this.  At the moment I think the solution is quite good compared to the
previous near unusable situation.

BTW - I just realised some of the specific timings in my previous post are
wrong but the principles are correct.

Bryan




More information about the MPlayer-users mailing list