I found this to be useful for me, however I&#39;m using PAL@50Hz and not NTSC colour encoding.<br><br><a href="http://www.linuxis.us/linux/media/howto/linux-htpc/video_card_configuration.html">http://www.linuxis.us/linux/media/howto/linux-htpc/video_card_configuration.html</a><br>
<br>Nice background information.<br><br><div><span class="gmail_quote">On 17/08/2008, <b class="gmail_sendername">Thomas Hilber</b> &lt;<a href="mailto:vdr@toh.cx">vdr@toh.cx</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;">
On Sun, Aug 17, 2008 at 04:31:58PM +0100, Gavin Hamill wrote:<br> &gt; CPU usage rather than userspace. Due to the critical timing nature of<br> &gt; the patches, they need to have nearly the whole machine to themselves,<br>
 <br> <br>the patches are time critical as far as xine itself must time the<br> frames very accurately.<br> <br> Even my old 800Mhz Pentium with AGP-Radeon shows that indeed every<br> 40000usecs +-35usecs a frame comes to Xserver&#39;s PutImage().<br>
 <br> It&#39;s by far not neccessary for the patches to work to get frames that<br> accurately but it shows what is possible even on old and slow hardware.<br> <br> On Gavin&#39;s machine with PCI DMA problems we instead timed<br>
 40000usecs +-21000usecs a frame comes to the Xserver&#39;s PutImage().<br> <br> That is way too unstable. I think xine itself also can&#39;t cope with that.<br> At least it will show heavy jerkyness.<br> <br> Nonetheless I today released a new version of the patches with 100%<br>
 lesser sensivity to timing problems (see announcement of today).<br> <br> Cheers<br> <br>&nbsp;&nbsp; Thomas<br> <br><br> <br> _______________________________________________<br> vdr mailing list<br> <a href="mailto:vdr@linuxtv.org">vdr@linuxtv.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><br>