Re: Playback probs

Michael Collard wrote:

>On Wed, 2004-06-30 at 17:49, Nico Sabbi wrote:
>
>  
>
>>You clipped too much of the logs, otherwise you would have realized that
>>before that message mplayer printed "Your system is too slow to play 
>>this..."
>>showing
>>- a huge amount of dropped frames
>>- a very high audio_out %
>>- cache fill 0%.
>>I get the same problem on some low-bitrate satellite transponders.
>>It seems that mplayer is incurring in buffer underrun problems, that is
>>in data starvation, maybe because it decodes audio and video too fast,
>>faster than it can receive data from the card.
>>This happens because mplayer doesn't synchronize to to the PCR (the
>>reference clock associated to each program) but syncs audio and video
>>to each other( if you search in the archives of mplayer-users you can find
>>Arpi's explanation).
>>
>>I haven't found a definitive solution, yet, but you can somewhat reduce 
>>the problem
>>with some workarounds:
>>1) make sure you are using the last cvs
>>2) use the RTC, not the soundcard clock
>>3) use -mc 0.1
>>4) eventually slow down playback a little (unperceivable) bit with 
>>-speed 0.98
>>5) use a larger cache ( I use 8192)
>>    
>>
>
>So far I've changed the cache to 8192 and this has improved greatly.
>Still, I think that MPlayer should simply flush the buffers 
>

at this point they are totally empty

>and start
>again if this problem occurs. How hard would it be to add this
>capability do you think?
>
>Regards
>Michael collard
>
>  
>

reinit the whole cache, demux and decoding pipeline (stream is already 
setup),
possible in the case of DVB (which does something similar whe you change 
channel)
but very ugly.
1-2 months ago a guy posted a patch (or a link to a site) that made 
mplayer sync to a
network clock; it could be used as base for  synchronizing to the PCR 
(right solution).

        Nico