<div><span class="gmail_quote">On 10/22/06, <b class="gmail_sendername">C.Y.M</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Are you thinking that mplayer might be dropping bad frames more efficiently than<br>VDR? Is it possible that VDR is not dropping the bad frames properly, thus
<br>causing dvbplayer.c to struggle when processing/forwarding the video to the FF<br>DVB card? This is the command used when playing back DVB compliant VDR<br>recordings to a FF card with mplayer:<br><br>mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet
001.vdr<br><br>Notice that "-framedrop" is added to the command line. I wonder if that is the<br>reason why mplayer is "immune" to the a/v desync problem.<br><br>Best Regards.<br><br><br>_______________________________________________
<br>vdr mailing list<br><a href="mailto:email@example.com">firstname.lastname@example.org</a><br><a href="http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr">http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr</a><br></blockquote></div>
<div>Certainly I think the problem is that VDR is not properly doing sync, especially with DVB transmissions that are prone to error (e.g. DVB-T). I have tried virtually all of the hotplug firmwares and followed the DVB CVS driver for the last few months and it doesn't make any difference. I also use the cards digital output as well as the analogue out and it doesn't make any difference there is always sync problems, especially after a glitch in the stream. I think that VDR should regularly check and resync the audio to the video, if it doesn't already. If it does, then there is a problem in the process as it gets it wrong.