On 10/22/06, C.Y.M <[EMAIL PROTECTED]> wrote:
Are you thinking that mplayer might be dropping bad frames more efficiently than
VDR?  Is it possible that VDR is not dropping the bad frames properly, thus
causing dvbplayer.c to struggle when processing/forwarding the video to the FF
DVB card? This is the command used when playing back DVB compliant VDR
recordings to a FF card with mplayer:

mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr

Notice that "-framedrop" is added to the command line.  I wonder if that is the
reason why mplayer is "immune" to the a/v desync problem.

Best Regards.


_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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.
 
Regards,
 
Morfsta

 
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Reply via email to