wow, when I buy an AMD card I will sure look up your code. :)
currently I'm still using a pentium 4, 2.4GHz machine with nvidia AGP 440MX
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
"downgrade" the driver to get the proper output.
With these options in my xorg.conf to disable the driver's auto settings.
ModeLine "720x576PAL" 27.50 720 744 800 880 576 582 588 625 -hsync
ModeLine "[EMAIL PROTECTED]" 14.0625 720 760 800 900 576 582 588 625 -hsync
Option "UseEDIDFreqs" "FALSE"
Option "UseEDIDDpi" "FALSE"
Option "ModeValidation" "NoEdidModes"
xvidtune reports this on DISPLAY=:0.1
"720x576" 27.50 720 744 800 880 576 582 588 625 -hsync
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.
2008/7/22 Thomas Hilber <[EMAIL PROTECTED]>:
> Hi list,
> the last few days I made some interesting experiences with VGA cards I
> now want to share with you.
> develop a budget card based VDR with PAL/RGB output and FF like output
> as we all know current VGA graphics output quality suffers from certain
> limitations. Graphics cards known so far operate at a fixed frame rate
> not properly synchronized with the stream.
> Thus fields or even frames do often not appear the right time at the ouput.
> Some are doubled others are lost. Finally leading to more or less jerky
> To a certain degree you can workaround this by software deinterlacing.
> At the cost of worse picture quality when playing interlaced material. Also
> CPU load is considerably increased by that.
> It appeared to be a privilege of so called full featured cards (expensive
> running proprietary firmware) to output true RGB PAL at variable framerate.
> Thus always providing full stream synchronicity.
> I've always been bothered by that and finally started to develop a few
> with the goal in mind to overcome these VGA graphics limitations.
> graphics cards basically are not designed for variable frame rates. Once
> you have setup their timing you are not provided any means like registers
> synchronize the frame rate with external timers. But that's exactly what's
> needed for signal output to stay in sync with the frame rate provided by
> xine-lib or other software decoders.
> To extend/reduce the overall time between vertical retrace I first
> dynamically added/removed a few scanlines to the modeline but with bad
> results. By doing so the picture was visibly jumping on the TV set.
> After some further experimenting I finally found a solution to fine adjust
> frame rate of my elderly Radeon type card. This time without any bad side
> effects on the screen.
> Just trimming the length of a few scanlines during vertical retrace
> period does the trick.
> Then I tried to implement the new functionality by applying only minimum
> changes to my current VDR development system. Radeon DRM driver is
> suited for that. I just had to add a few lines of code there.
> I finally ended up in a small patch against Radeon DRM driver and a even
> smaller one against xine-lib. The last one also could take place directly
> in the Xserver. Please see attachments for code samples.
> When xine-lib calls PutImage() it checks whether to increase/decrease
> Xservers frame rate. This way after a short adaption phase xine-lib can
> place it's PutImage() calls right in the middle between 2 adjacent vertical
> blanking intervals. This provides maximum immunity against jitter. And
> even better: no more frames/fields are lost due to stream and graphics
> card frequency drift.
> Because we now cease from any deinterlacing we enjoy discontinuation of
> all its disadvantages:
> If driving a device with native interlaced input (e.g. a traditional TV Set
> or modern TFT with good RGB support) we have no deinterlacing artifacts
> Since softdecoders now are relieved of any CPU intensive deinterlacing
> we now can build cheap budget card based VDRs with slow CPUs.
> Please find attached 2 small patches showing you the basic idea and a
> description of my test environment. The project is far from complete but
> even at this early stage of development shows promising results.
> It should give you some rough ideas how to recycle your old hardware to a
> smoothly running budget VDR with high quality RGB video output.
> some suggestions what to do next:
> - detection of initial field parity
> - faster initial frame rate synchronisation after starting replay
> - remove some hard coded constants (special dependencies on my system's
> Some more information about the project is also available here
> Currently it's all based on Radeons but I'll try to also port it to other
> type of VGA cards. There will be some updates in the near future. stay
> vdr mailing list
vdr mailing list