[MPlayer-dev-eng] [PATCH] dvb fix

Nico nsabbi at libero.it
Mon Aug 25 15:41:02 CEST 2003

David Kuehling wrote:

>well, I might have found the cause for the crashing A-V sync engine with
>DVB streaming input.  As I said, framerate is at about 3fps while
>playing directly from DVB without cache, while audio plays at normal
>speed.  CPU use is very low, so I tried to interrupt mplayer during that
>idle time.  A GDB backtrace shows, that it always hangs in poll:
>#0  0x4051fb90 in poll () from /lib/libc.so.6
>#1  0x0819cfdb in dvb_streaming_read (stream=0x33, 
>    buffer=0x84d283c "\2124@\2071r\tA.ç\237\223?Æï8¦b}\024z\006xó\004\231\036ë^\025CV?\016\220ìsg¢\220þ³\v\001\024qà\003G\001\001\032UÊ\203¨£\230~yÜ\211-oiD:\2110\202@\217\217ßËß\034Ñà}Q:\230¤V\022°ØÃLKËÞ-\006ÑF\027¡Çæ\200ÈÒ^s$/[\234 \021ÑGYñ£¯eH\206\016?ÐLE­w£X¥ÙèÏC\0312h¢Ñ!\001×FëÚ\026Ö\205µ¹M9\225XdÑ\235«¶ÓÎk\024yÌ&ØR²ij\224xú\001\235\t\216¢0¸áô\022ý`S5)¢\204ú³SÙ0ÐJm"..., size=2048)
>    at dvbin.c:293
>#2  0x08171cd4 in stream_fill_buffer (s=0x84d27e0) at stream.c:225
>#3  0x08166f8d in cache_stream_fill_buffer (s=0x84d27e0) at cache2.c:298
>#4  0x0819654f in ts_parse (demuxer=0x84dfa50, es=0xbfffe7b0, 
>    packet=0xbfffe6e0 "D\001\001\031\005", probe=0) at stream.h:183
>#5  0x08196c8e in demux_ts_fill_buffer (demuxer=0x84dfa50) at demux_ts.c:1748
>#6  0x0816dc29 in demux_fill_buffer (demux=0x33, ds=0x1) at demuxer.c:364
>#7  0x0816de01 in ds_fill_buffer (ds=0x84e02b8) at demuxer.c:416
>#8  0x0816deac in demux_read_data (ds=0x84e02b8, mem=0xbfffe8e0 "ÿü¤`", len=4)
>    at demuxer.c:435
>It seems, that DVB input wants to read more data than available. 
it reads as much data as is required by the demuxer, so it has to poll 
before reading

> As
>the audio stream calls for continous data, and audio cannot be slowed
>down, the effect doesn't stop and just goes on.  Instead the code should
>check very carefully that enough data are available before initiating
>audio playback.  If that doesn't help, maybe a greater stream-buffer
>would be helpful.  
you can modify the size of the stream buffer in stream.h


>Another possible cause is, that my soundcard's sample rate may be
>slightly faster than the sampling rate of the broadcasted audio.  
it's always 48 Khz,  can your card playback it correctly?
if not you can add -srate 44100 (or something like that) to the command line

>my soundcard, which provides the base-time for playback, makes audio
>crush to the edge of the input buffer, where it will cause video delays
>due to missing data.
video bitrate is so much higher than audio bitrate that it's impossible  
that  video is missing, if I understand what you mean

>Actually, MPlayer might not be very usuable for digital streaming audio,
>as long as it cannot resample audio or drop audio frames/insert gaps.
try to use a radio channel, or a video channel with vid set to 0 in 


More information about the MPlayer-dev-eng mailing list