[vdr] kvdr-Xv & deinterlacing support

[Guido Fiala <gfiala@s.netic.de>]

Hallo together,

found some time to make a test with kvdr and Xv-support.
Basically it's 90% working and looks promising
- including optional 50Hz upscale-deinterlacing!

(It takes about 50% CPU-load at my P2-450, mainly falling upon memcpy()=10% 
and XSync() the rest, XvShmPutImage() only 10us/per call).

---
Can need some help - adressed to programmers and interested people:

There are however some problems/question remaining:
1. The test of the deinterlacing at "N24" scroll texts show a clear 
improvement of readability in deinterlacing mode, but it looks only like 
25Hz, although the software says me it's 50Hz. Maybe the XSync() does'nt 
actually show the frame upon the screen?

2. And the only "don't":
*None* of the capture formats the dvb/tv-card supports is directly supported 
by the Xv-extension of the X-Server. One would have to call an additional 
RGB2YUV-conversion routine eating CPU.
Are there graphics cards which support more formats then shown below (extract 
from the output of xvinfo at my V3k) , could someone please send me the 
output of an Geforce and a Rage card or better a solution ?-)

---
Number of image formats: 4
      id: 0x32595559 (YUY2)
        guid: 59555932-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)
      id: 0x59565955 (UYVY)
        guid: 55595659-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)
      id: 0x32315659 (YV12)
        guid: 59563132-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
      id: 0x30323449 (I420)
        guid: 49343230-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
---
(a 16bit format as a base for conversion to RGB is also not the best i can 
think of...)

3. If the above is not required it would theoretically be possible to get rid 
of the memcpy() too by making the Xv-extension believe an 768x576 images is 
actually 1536x288 image and showing the left and right half spaced by 20ms.
Unfortunately the XvPutImage() routine takes much more cpu than the 
shm-variant, despite that the video-card directly writes into the memory of 
the XvImage...
Is there a way to make the video-card writing into the XvShmImage or the 
oposite way? The advantage would be, that the CPU-load would decrease about 
10-20%.

If someone likes to experiment with it, i can upload the upcoming kvdr-0.5a 
at the usual place...