<div dir="ltr">wow, when I buy an AMD card I will sure look up your code. :)<br><br>currently I&#39;m still using a pentium 4, 2.4GHz machine with nvidia AGP 440MX card, <br><br>only way to get that to work properly was with the older nvidia drivers 71.86.0 , apparently the newer drivers forces PAL or any other TV Standard to run @60Hz instead of 50Hz, which is what my broadcast is. So I had to &quot;downgrade&quot; the driver to get the proper output.<br>
<br>With these options in my xorg.conf to disable the driver&#39;s auto settings.<br><br>Section &quot;Monitor&quot;<br>
&nbsp;&nbsp;&nbsp; .<br>
&nbsp;&nbsp;&nbsp; .<br>
&nbsp;&nbsp;&nbsp; ModeLine &quot;720x576PAL&quot;&nbsp;&nbsp; 27.50&nbsp;&nbsp; 720 744 800 880 576 582 588 625 -hsync -vsync<br>
&nbsp;&nbsp;&nbsp; ModeLine &quot;720x576@50i&quot;&nbsp; 14.0625 720 760 800 900 576 582 588 625 -hsync -vsync interlace<br>
&nbsp;&nbsp;&nbsp; .<br>
EndSection<br><br>Section &quot;Screen&quot;<br>&nbsp;&nbsp;&nbsp; .<br>&nbsp;&nbsp;&nbsp; .<br>&nbsp;&nbsp;&nbsp; Option&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;UseEDIDFreqs&quot; &quot;FALSE&quot;<br>&nbsp;&nbsp;&nbsp; Option&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;UseEDIDDpi&quot; &quot;FALSE&quot;<br>&nbsp;&nbsp;&nbsp; Option&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;ModeValidation&quot; &quot;NoEdidModes&quot;<br>
&nbsp;&nbsp;&nbsp; SubSection &quot;Display&quot;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Modes&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;720x576PAL&quot;<br>&nbsp;&nbsp;&nbsp; EndSubSection<br>&nbsp;&nbsp;&nbsp; .<br>EndSection<br><br>xvidtune reports this on DISPLAY=:0.1<br>
&nbsp;&quot;720x576&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 27.50&nbsp;&nbsp;&nbsp; 720&nbsp; 744&nbsp; 800&nbsp; 880&nbsp;&nbsp;&nbsp; 576&nbsp; 582&nbsp; 588&nbsp; 625 -hsync -vsync<br><br>cpu load is 10% with xineliboutput set to use xvmc, my cpu fan even turns off, it only kicks in when I view a xvid/divx type movie.<br>
<br>Theunis<br><br><div class="gmail_quote">2008/7/22 Thomas Hilber &lt;<a href="mailto:vdr@toh.cx">vdr@toh.cx</a>&gt;:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi list,<br>
<br>
the last few days I made some interesting experiences with VGA cards I<br>
now want to share with you.<br>
<br>
goal<br>
----<br>
<br>
develop a budget card based VDR with PAL/RGB output and FF like output quality<br>
<br>
problem<br>
-------<br>
<br>
as we all know current VGA graphics output quality suffers from certain<br>
limitations. Graphics cards known so far operate at a fixed frame rate<br>
not properly synchronized with the stream.<br>
Thus fields or even frames do often not appear the right time at the ouput.<br>
Some are doubled others are lost. Finally leading to more or less jerky<br>
playback.<br>
<br>
To a certain degree you can workaround this by software deinterlacing.<br>
At the cost of worse picture quality when playing interlaced material. Also<br>
CPU load is considerably increased by that.<br>
<br>
It appeared to be a privilege of so called full featured cards (expensive cards<br>
running proprietary firmware) to output true RGB PAL at variable framerate.<br>
Thus always providing full stream synchronicity.<br>
<br>
I&#39;ve always been bothered by that and finally started to develop a few patches<br>
with the goal in mind to overcome these VGA graphics limitations.<br>
<br>
solution<br>
--------<br>
<br>
graphics cards basically are not designed for variable frame rates. Once<br>
you have setup their timing you are not provided any means like registers to<br>
synchronize the frame rate with external timers. But that&#39;s exactly what&#39;s<br>
needed for signal output to stay in sync with the frame rate provided by<br>
xine-lib or other software decoders.<br>
<br>
To extend/reduce the overall time between vertical retrace I first<br>
dynamically added/removed a few scanlines to the modeline but with bad<br>
results. By doing so the picture was visibly jumping on the TV set.<br>
<br>
After some further experimenting I finally found a solution to fine adjust the<br>
frame rate of my elderly Radeon type card. This time without any bad side<br>
effects on the screen.<br>
<br>
Just trimming the length of a few scanlines during vertical retrace<br>
period does the trick.<br>
<br>
Then I tried to implement the new functionality by applying only minimum<br>
changes to my current VDR development system. Radeon DRM driver is perfectly<br>
suited for that. I just had to add a few lines of code there.<br>
<br>
I finally ended up in a small patch against Radeon DRM driver and a even<br>
smaller one against xine-lib. The last one also could take place directly<br>
in the Xserver. Please see attachments for code samples.<br>
<br>
When xine-lib calls PutImage() it checks whether to increase/decrease<br>
Xservers frame rate. This way after a short adaption phase xine-lib can<br>
place it&#39;s PutImage() calls right in the middle between 2 adjacent vertical<br>
blanking intervals. This provides maximum immunity against jitter. And<br>
even better: no more frames/fields are lost due to stream and graphics<br>
card frequency drift.<br>
<br>
Because we now cease from any deinterlacing we enjoy discontinuation of<br>
all its disadvantages:<br>
<br>
If driving a device with native interlaced input (e.g. a traditional TV Set<br>
or modern TFT with good RGB support) we have no deinterlacing artifacts<br>
anymore.<br>
<br>
Since softdecoders now are relieved of any CPU intensive deinterlacing<br>
we now can build cheap budget card based VDRs with slow CPUs.<br>
<br>
Please find attached 2 small patches showing you the basic idea and a<br>
description of my test environment. The project is far from complete but<br>
even at this early stage of development shows promising results.<br>
<br>
It should give you some rough ideas how to recycle your old hardware to a<br>
smoothly running budget VDR with high quality RGB video output.<br>
<br>
some suggestions what to do next:<br>
- detection of initial field parity<br>
- faster initial frame rate synchronisation after starting replay<br>
- remove some hard coded constants (special dependencies on my system&#39;s timing)<br>
<br>
Some more information about the project is also available here<br>
<a href="http://www.vdr-portal.de/board/thread.php?threadid=78480" target="_blank">http://www.vdr-portal.de/board/thread.php?threadid=78480</a><br>
<br>
Currently it&#39;s all based on Radeons but I&#39;ll try to also port it to other<br>
type of VGA cards. There will be some updates in the near future. stay tuned.<br>
<font color="#888888"><br>
-Thomas<br>
<br>
</font><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" target="_blank">http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr</a><br>
<br></blockquote></div><br></div>