[Mplayer-dvb] Playback probs

[Nico Sabbi]

Michael wrote:

>I am having a couple of problems with mplayer and DVB-T streaming:
>
>I'm not really certain about what it indicates but I get this right before 
>mplayer dies.
>
>-snip-
>Too many audio packets in the buffer: (4096 in 751616 bytes).
>Maybe you are playing a non-interleaved stream/file or the codec failed?
>For AVI files, try to force non-interleaved mode with the -ni option.
>ds_fill_buffer: EOF reached (stream: video)
>A:37422.5 V:37453.4 A-V:-30.885 ct:  5.347  95264/95264   8%  3%  7.7%
>1837 0 47 EOF code: 1
>-snip-
>
>After the above output I tried with the -ni options but got much the same:
>
>-snip-
>Too many audio packets in the buffer: (4096 in 751600 bytes).
>Maybe you are playing a non-interleaved stream/file or the codec failed?
>For AVI files, try to force non-interleaved mode with the -ni option.
>ds_fill_buffer: EOF reached (stream: video)
>A:43589.0 V:43619.9 A-V:-30.912 ct:  5.146  105343/105343   8%  3%  7.2%
>1788 0 EOF code: 1
>-snip-
>
>I am running MPlayer CVS (29062004) with the -cache 4096 parameter. 
>
>Exactly the same thing happens too when using dvbstream and mplayer in the 
>usual way. Any ideas or pointers?
>
>Regards
>Michael Collard
>
>  
>

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)

Still searching for a definitive solution....

            Nico