[vdr] Re: kvdr-Xv & deinterlacing support

["Start-Games Dev." <webdev@start-games.com>]

I'm an everyday kvdr user and have KDE 2 installed
let me know if i can help.
I've already noticed some weird video behaviour when using VDR & Mplayer but
i've not used it so much..

Marc

----- Original Message -----
From: "Guido Fiala" <gfiala@s.netic.de>
To: <vdr@linuxtv.org>
Sent: Monday, April 01, 2002 12:16 PM
Subject: [vdr] kvdr-Xv & deinterlacing support


> 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...
>
>
>
>