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

[Georgi Petrov]

Hi Alban,

Thanks for answering me. It's always better to know someone cares about what
you do :)

>> 3) tdfx_vid: *Could be the best*, but lacks subtitle support!!! This
>> is serious.
>vf_expand ? Imho there is no need to dup even more code in MPlayer. But
>feel free to do it.

??????????????????????

I didn't understand it - how can -vf expand help me to see the subtitles, when
they aren't implemented in the driver. I don't fully understand the internals
of mplayer, but in your driver osd_something function is empty. Shouldn't this
function place the subtitles on the screen, or this work is handled elsewhere?

I'm really incompetent here :) Tell me!

>> http://zebra.fh-weingarten.de/~maxi/html/mplayer-users/2003-09/msg00681.html
>> 
>> 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!
>
>iirc there is a limitation. The bilinear filtering can only be enabled
>in 1x mode (whatever that is) according to the specs. i have. So the code
>check that and then enable bilinear filtering if possible.
>Now if you can set all the time a patch is welcome.

Yes, that's true, BUT: In your code you check wheter 1x or 2x mode is turned
on. If 1x is turned on, you enable bilinear, if 2x is on, you disable it.

The right way isn't to check which mode is enabled (bacause on my card 2x mode
is ALWAYS turned on), but explicitly to enable 1x mode and then enable bilinear
filtering. Acually on my post I've included the patch. Sorry - it's not diff's
output, but if you take a look at it, you'll see that it's really easy to
correct it :) No more than 3 lines of code :)

>It's at kernel level bcs you need to interface with the AGP mem.
>I never was able to use the AGP stuff from user space (even the simplest
>code samples failed miserably) so i turned to a kernel module.
>I was also nice to see how you do modules ;)

Yeah... That's true. I just want to see how the VIDIX driver will perform in
comparison to yours. It would be fun :) Of course AGP memcpy is faster, but...
I'm just curious what will happend :) Right now my driver gives me less dropped
frames. It still doesn't display correctly NOTHING, but that's only some
adjustments I have to make. I have one video, on which:

1) XVideo gives me ~ 1300 dropped frames
2) tdfx_vid ~ 900
3) my driver ~ 200

Of course there may be some mistake from my side, because I still have no idea
what is pitch, stride, how the whole thing is arranged in memory, but after 1
week ENDLESS coding I managed to:

1) Implement almost all VIDIX needed functions (some partly, no dobule
buffering)
2) Start overlay (with proper size/format) and give VIDIX it's memory address,
size, etc.

Now I have to figure how exactly are Y,U and V planes arranged, which offsets
between what I have to set and... what the f*** I have to do at all!!!

Now VIDIX writes there, but what's on the screen hardly can be called video
:))) It moves and there are SOME lines displayed correctly, but the whole thing
is heavily unarranged. I'm still experimenting. I should adjust offsets and a
couple of things, but it's really hard when you don't know how EXACTLY it works
inside :(

BTW, writing kernel module is WAAAAAY beyound my skills :)))
Ohh, yes - can the driver be modified so it can be inserted in 2.6.x kernel?

>I did considered VIDIX. But i soon understood VIDIX will never ever fit
>with the banshee design.
>VIDIX assume the card have a nice overlay wich support a given number of
format.
>The banshee overlay only support YUY2 and BGR16.

Why not use -vf yuy2 always? At the moment when VIDIX tries to find matching
colorspace, I just reject YV12 and say one big YES to YUY2. Well, I think that
BGR16 on the other side isn't big issue - I mean that no codec in libavcodec
uses RGB color space as far as I know. And even if some does, no MPEG4 codec
does it :)

>That's it, it can't even downscale. For all the rest you need to use
>the internal converter/scaler.

I think that downscaling isn't big issue either. I mean - how often do you need
do downscale some video? I personally don't need it and I see no one, who will
need it :)

>So in VIDIX to correctly support all colorspace you would need to implement
>all this magic inside the driver. That was not an acceptable solution.

Why don't just reject what's not supported by the driver and leave mplayer to
do the hard work? For example since YV12 is the colorspace almost every codec
uses, I just say NO to YV12 and the internal converter gives me YUY2 -
converted using MMX and it's way faster than I could ever do it in the driver.

>So i wrote tdfx_vid wich only give access to the basics functions of the
>card. Then the vo do all the needed black magic to have these bit showup
>on the screen as fast as possible :)

Yeah, that's what I also mean :)

>Anyway good luck with VIDIX if you really thinks that's worth it :)

Well, if it could give me 900 -> 200 dropped frames on some movie, I'll be
satisfied. Even if I do something wrong at the moment to have this framedrop
(e.g. asking from VIDIX to write smaller amount of information than really
needed), I'll be happy, because that will be my first "driver" :)

Thank you a lot. Without tdfx_vid, I would never succeed.

gogothebee



__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com