VDR User wrote:
> On 1/31/07, *Klaus Schmidinger* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>     Ville Rannikko wrote:
>     > Hi!
>     >
>     > The newest firmware for FF cards did not completely fix the AV desync
>     > problems for me. According to information from Werner the problem
>     > happens when small video frames fill the decoder buffer with over 2
>     > seconds of data. So I made this patch for dvbplayer.c to stop it from
>     > uploading more PES frames to decoder when STC/PTS difference is more
>     > than 2 seconds. This seems to fix the remaining problems for me,
>     but I
>     > have not tested it much. The PTS/STC-code has been mostly taken
>     from the
>     > dvb-subtitles plugin. Comments, please
>     While this may actually help in your case, I'm not particularly fond
>     of this. The cDvbPlayer shouldn't have to worry about this. It takes
>     care
>     that data is sent to the player device fast enough to avoid underruns,
>     but that's all it should have to care about. It's the device's (driver
>     and firmware) job to play the data correctly.
> From what he's saying, the problem is buffer overrun's, not underrun's. 
> Too much data is being sent and the device isn't able to keep up.  If
> that's the case then it would make sense for vdr to have a user setting
> to limit how many seconds (or milliseconds perhaps?) worth of data is
> sent to the buffer.  I can't think of any reason not to add such a
> feature if it means better usability for the end-user.

If the device can't take any more data, it should just refuse to
accept it and return from the write() call without anything written.


vdr mailing list

Reply via email to