Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: kvdr-Xv & deinterlacing support
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...
Home |
Main Index |
Thread Index