[MPlayer-dev-eng] [PATCH] dvb fix
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?ÐLEw£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
>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
#define STREAM_BUFFER_SIZE 2048
>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