Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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...
Home |
Main Index |
Thread Index