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

[David Kuehling]

>>>>> "Nico" == Nico  <nsabbi at libero.it> writes:

> David Kuehling wrote:

>> 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

This is not classical polling.  You wait for events on the file
descriptor via poll, with a timeout of half a second.  MPlayer is
event-loop-based without any threads.  Your code slows the main playing
loop down to a crawl, if no data are available immediately.  As the main
event loop of mplayer only displays one frame per cycle, video will
never be able to catch up with audio.  The situation is strange.  Your
DVB input code seems to have certain expactations about how much data it
can expect to read from the stream.  In my setup with DVB-t Berlin it
always requests slightly too much data.  It always gets the data it
wants, but also it always has to wait for it for about 0.3 seconds.

>> 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

> #define STREAM_BUFFER_SIZE 2048

I already tried with a value of 16768 and it didn't help.

>> 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 never had any problems with DVDs and 48KHz audio.  I also
tried -srate with various rates and it didn't help.  (actually, srate
doesn't seem to work with mplayer...)

>> Thus 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

Missing data refer to the effect where dvb_streaming_read is called and
blocks since not enough data are available.

David

-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40