[vdr] Re: kvdr-Xv & deinterlacing support

[Mirko =?ISO-8859-15?Q?G=FCnther?= <mi.guenther@ib-helms.de>]

Guido Fiala wrote:

>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...
>
>
>
>
xine uses also Xv as plugin. Maybe you can find your anwsers there...