<div><span class="gmail_quote">On 1/31/07, <b class="gmail_sendername">Klaus Schmidinger</b> &lt;<a href="mailto:Klaus.Schmidinger@cadsoft.de">Klaus.Schmidinger@cadsoft.de</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ville Rannikko wrote:<br>&gt; Hi!<br>&gt;<br>&gt; The newest firmware for FF cards did not completely fix the AV desync<br>&gt; problems for me. According to information from Werner the problem<br>&gt; happens when small video frames fill the decoder buffer with over 2
<br>&gt; seconds of data. So I made this patch for dvbplayer.c to stop it from<br>&gt; uploading more PES frames to decoder when STC/PTS difference is more<br>&gt; than 2 seconds. This seems to fix the remaining problems for me, but I
<br>&gt; have not tested it much. The PTS/STC-code has been mostly taken from the<br>&gt; dvb-subtitles plugin. Comments, please<br><br>While this may actually help in your case, I&#39;m not particularly fond<br>of this. The cDvbPlayer shouldn&#39;t have to worry about this. It takes care
<br>that data is sent to the player device fast enough to avoid underruns,<br>but that&#39;s all it should have to care about. It&#39;s the device&#39;s (driver<br>and firmware) job to play the data correctly.<br></blockquote>
</div><br>From what he&#39;s saying, the problem is buffer overrun&#39;s, not underrun&#39;s.&nbsp; Too much data is being sent and the device isn&#39;t able to keep up.&nbsp; If that&#39;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.&nbsp; I can&#39;t think of any reason not to add such a feature if it means better usability for the end-user.
<br><br>That&#39;s my opinion anyways. <br>