[MPlayer-dev-eng] Should I write Voodoo Banshee VIDIX driver?

Georgi Petrov gogothebee at yahoo.com
Sat Mar 13 08:18:18 CET 2004

A'rpi and Diego, thank you people

Until today I had hard time locating tdfx driver in the CVS tree, but
last night I downloaded it's source. Yesterday I ported what I could
from tdfx_vid and by looking through other VIDIX drivers. Now I have
the best - XFree86's tdfx :)

The Banshee VIDIX driver is *almost* ready for alpha stage testing
(at the moment it displays something, but it's completely scrambled:)
Today I have ~ 8-9 hours to develop and I think I'll be ready with at
least working from first sight driver in a week :)

As nothing will change in terms of CPU usage when I fix the displayed
image, I can say that what I measured now is lower than with XVideo.
It seems that this driver will be faster than Xv.

One question (I'm curious): Direct Rendering. I know about method 1
and method 2 and the question is:

1) With libavcodec and XVideo which method is possible/working?
2) With libavcodec and VIDIX  which method is possible/working?

That's all for now. When I have at least beta version, I'll publish
the sources, so anyone could help further :)

Ahhh, yes, my motivation after all - I mean why I write the VIDIX
driver, when there are XVideo, tdfxfb and tdfx_vid:

Weaknesses of each one:

1) XVideo: IMHO this is the best from the three. The problem - it's
little slow and the last few (2-4) lines from the image are almost
always incorrect (and flicking). I found no explanation and every
time I had to use -vf crop with height -4 lines.

I found the same problem with xine, so it's XVideo dependent issue
with the Banshee :(

Otherwise XVideo is right, I think. I ask once again: how does it
perform DR with libavcodec?

2) tdfxfb: Very nice and good idea, BUT - it doesn't create overlay.
Why is this bad? Well, the problem is BIG. When the movie is resized,
the driver tells Banshee source and destination dimensions, BUT
without overlay Banshee performs stretching by using "nearest
neighbour" (spelling?) or so called point stretching filter and not
bilinear. Unfortunately the high quality bilinear filtering can't be
turned on without using overlay - Banshee limitation. The result:
quality suffers when resizing. This is serious problem. I doubt many
people have figured it out, but it's so. The picture looks ugly,
compared to XVideo's overlay bilinear filtered image.

3) tdfx_vid: *Could be the best*, but lacks subtitle support!!! This
is serious. Also, refer to one of my previous posts:


There I explain that tdfx_vid CAN turn bilinear filtering on, but by
default it doesn't! Can be fixed by ~2 lines patch. Result? Again
poor qulity when resizing!

Also I don't like the idea of having it as a kernel module, don't
know why :) Just this can't be the way :) BTW, I think it can't be
inserted in 2.6.x kernel, is it so? Ohhh, problems...

On the other side, I think that VIDIX driver will solve all of those
problems. Wish me luck :)

Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam

More information about the MPlayer-dev-eng mailing list