The following quote is from the mplayer list, hopefully we might get a solution to this problem soon. Bryan Alton Wrote: > 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 delat is aout 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.
-- Neil Sleightholm _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
