Unscrupulous nagging about Xvid/DXVA

[trbarry]

For some reason I seem to be allergic to learning about how DirectShow programming really works. I've had various DirectX SDK's for a couple years now but still don't know much about it.

But I know all the DSF-writing wizards seem to hang out here. And I believe that with DXVA it is now possible to get access to hardware IDCT and motion compensation on modern video cards from ATI, Geforce etc.

So surely someone here knows what it would take to have DXVA support for mpeg4 playback. Can it be done now without having to sign an NDA with someone???.

The difference in performance would make it possible to play large clips (like my 1280x720p HDTV) at full speed or to add features like IVTC and deinterlacing to smaller ones. Or maybe both.

Anyone willing to jump in and explain all this? Or even look into writing it? ;)

Please don't everyone just stare at your shoes now.

- Tom

[trbarry]

Hey, nobody else cares to admit they don't understand it either? ;)

Is it part of that stuff that avih calls newclear fizzics?

[Nic]

I understand it, but have never heard of it...& have no idea on how to do it.... :)

Ill try a google search for info over the weekend...see if I can get a better understanding. :)

-Nic

[avih]

hehe. it always sounds to me like it's too much work and too much M$ specific to spend the time learning it :)

then again, if u find a page with a crash course about deep dshow programming, i'd like to read it as well :)

[Razor04]

It seems as though it would be a lot of work, though I have to admit that it would be really nice for my graphics card to accelerate the decoding of mpg4. While I can currently handle the various mpg4 codecs just fine, I would rather be able to use a direct show filter that can access my cards idct decoding function instead of buying a mpg4 decoder too. Just my 2 cents, hopefully it can be implemented eventually. I would offer to help, but I am no programmer.

[trbarry]

It seems as though it would be a lot of work, though I have to admit that it would be really nice for my graphics card to accelerate the decoding of mpg4.

I actually suspect that it would not be that many lines of code, just some parameters passed to DirectX/DirectShow. But it's probably a bunch of "eye of newt, wing of bat" stuff that finally needs some last magic parameter to turn it on. And that last parameter is probably buried under NDA somewhere.

So I'm throwing out the gauntlet here. Just because I'm too stupid to understand all the DirectX SDK doc doens't mean all the rest of you are too. Or does it? ;)

- Tom

[Koepi]

hö? %P
(in french it would be "hein?", and in english I don't know of anything similar for expressing "I don't understand and I'm uncontrolled loosing fluids from my mouth." ;) )

Regards,
Koepi

[-h]

I actually suspect that it would not be that many lines of code, just some parameters passed to DirectX/DirectShow. But it's probably a bunch of "eye of newt, wing of bat" stuff that finally needs some last magic parameter to turn it on. And that last parameter is probably buried under NDA somewhere.

Probably not, but you'd have to modify core remember - hardware idct might not be such a pain (just hijack the existing idct() function pointer to possibly a wrapper function for the hardware call), but motion compensation is quite complex and would need quite a bit of wrapping.

And of course, this all means converting core itself into a directshow module (no more linking dshow against the dll or lib file), as internal functions will have to directly call dshow.

-h

[trbarry]

-h

Dunno. If it already calls by function pointer now then maybe a dshow filter could supply one at init time, at least for a hardware IDCT function. Would this really change core much? I already put in sse2 idct & sad16 though I didn't release them because of the nasm problems compiling sse2 with old releases. But both of those already store a pointer to the correct function at init, don't they? I sure hope so because I changed it. ;)

I don't know enough about mpeg2/mpeg4 to know how well mpeg2 style hardware motion comp support would help mpeg4 decoding.

But I still think that one of the major advantages that mpeg2 still has over mpeg4 is the hardware support already built into todays graphics cards for playing DVD's. That allows folks to play somewhat higher resolution video from mpeg2 at full speed. This in turn makes them think that mpeg2 can do higher resolution pictures. That bothers me.

And haven't any of the Unix folks already figured out how to access ATI and nvidea card hardware support?

- Tom

[-h]

Dunno. If it already calls by function pointer now then maybe a dshow filter could supply one at init time, at least for a hardware IDCT function. Would this really change core much? I already put in sse2 idct & sad16 though I didn't release them because of the nasm problems compiling sse2 with old releases. But both of those already store a pointer to the correct function at init, don't they? I sure hope so because I changed it. ;)

It wouldn't change core much, *if* whatever dshow does is simply an in-place iDCT operation on a contiguous array of 16 bit signed ints ;) Hence the wrapping functions.

I don't know enough about mpeg2/mpeg4 to know how well mpeg2 style hardware motion comp support would help mpeg4 decoding.

They're extremely similar, though I'm not sure about the rounding during interpolation. They should be mostly identical. However it works, the function interface will be the "interesting" bit to move into core - does it need an array of MVs? What kind of formatting? Will core's array structure have to be altered?

And haven't any of the Unix folks already figured out how to access ATI and nvidea card hardware support?

Don't know. Things like this (http://elecard-med.com/forum/viewthread.php?tid=13) are a bit of a worry.

-h

[chemmajik]

LinuxVideo.org or http://gatos.sourceforge.net/ discusses some Radeon stuff. I believe XFree86 in all honesty controls the accelerating part, I'm sure its prob in a elf compiled library or similar under NDA.
http://www.google.com/search?hl=en&q=+site:www.xfree86.org+DXVA

Microsoft DXVA description
http://www.microsoft.com/hwdev/tech/stream/DirectX_VA/default.asp

[trbarry]

I went to the Microsoft site and started reading about this again, and my brain hurts. It seems it is very hard to put only a little bit of anything Microsoft into a program.

But maybe some smart person can figure it out.

- Tom

[chemmajik]

Its all in the overlay mixer from making my brain hurt also. It cannot be done without any source code examples, much less no API.
I need to email you a doc sheet it may have some stuff missing.
This is what I found in the ATI driver binary's.
DXVA_PM4Size
DXVA_MacroBlockPerBuffer
DXVA_USE_IMC4
DXVA
MPEG2_D MPEG2_D_CONFIG MPEG2_C MPEG2_C_CONFIG MPEG2_B MPEG2_B_CONFIG MPEG2_A MPEG2_A_CONFIG
MPEG1_A MPEG1_A_CONFIG
H263_F H263_F_CONFIG H263_E H263_E_CONFIG H263_D H263_D_CONFIG H263_C H263_C_CONFIG H263_B H263_B_CONFIG H263_A H263_A_CONFIG
H261_B H261_B_CONFIG H261_A H261_A_CONFIG
SOFTWARE\ATI Technologies\DirectX VA\ [ATI LIB=WIN9X.DVDAUTH.LIB,4.13.1.1006]

DXVA_AYUV0
Max macroblock number (mc/dct type buffer) = 0x
Uncompressed surfaces fourcc = 0x
Number of uncompressed surfaces = DXVA: Destroy - accelerated from iDCT+MC
DXVA: Create - 0x
DVD_SPBLEND
DVD_SWDECRYPT 4.13.1.1006
DVD_DEBUGLEVEL SOFTWARE\ATI Technologies\DVD\ IDCT
PM4 Buffer Size = 0x ; uv-pitch = ; y-pitch = ; picture height =
Picture width =
DVD Auth Library Version = 0x
MCAM YV12

See there's a WIN9X.DVDAUTH.LIB.

NVidia from a older 21.85 set of drivers I only found
Direct3D DXVAEnable c:\ capture
UYVY ÿÿÿÿÿÿÿÿÿÿÿÿ
RAW8 ÿÿÿÿÿÿÿÿÿÿÿÿ
nvSetRenderTargetDX7: Can't create a stereo surface VPEENABLE \DirectDraw Œ

I'll continue in a new message. A line you maybe not seeing on microsoft.

[chemmajik]

First off DXVA uses B frames in its decode process, so before something would be implemented for XVid we have to wait for B frames are incorporated into the decoder. The Overlay mixer most likely in the filter process is where you might start. I did a filter graph it will allow you to place the overlay mixer before the video renderer & still work. But there are restrictions on what you can use the overlay mixer for. See this is what I think the linux guys may have done, they skipped all post/preprocessing & passed it thru a overlay, or they used only a section of mocomp3(motion compensation).

[trbarry]

chemmajik -

This is like buying a gas station just so I can change a tire.

But email me at the www.trbarry.com link.

Bottom line, is there any hope? :confused:

- Tom

[Koepi]

Hehe chemmajik, you seem to have some knowledge about this matter...
Hopefully not only on linux :)

Do you have any idea how to control the overlay when you write a DSF? Maybe forcing an overlay mixer behind the own (XviD) DSF would be a solution, but I didn't find a way to do it... mind to help us out there? ;)

Best regards,
Koepi

[avih]

tom.

regarding your site, WHERE IS IT???

i remember browsing it and reading many reports u've written (yellow backgruond right?) about svcd and capturing and stuff some while ago, before i met u on this forum. i do remember it was an excellent site.

but now i see only this poem... which is cool, but where's the main index for the rest of the stuff? :)
-avi

[trbarry]

avih -

Nope, that wasn't me. I don't have the patience to maintain a real web site. For years now I've just posted individual files, so all I have is my silly poem with the email link.

And I only dragged that out of mothballs a couple months ago when neuron2 made fun of the blank page I had out there. ;)

- Tom

[chemmajik]

To be honest I'm no expert on the subject at all, I'm kinda rusty to be honest. I was working on this subject it seems like a year ago in depth, so lost alot of the information. I'm just code hacking right now. I'd really like to play with nic's post preprocessor code thou.
If you point me to what area is the key I might can figure some out. What I tripped out on was testing out the avic code changer, when we use divx4 dsf I noticed xvid made video's can be made to look as good or better then divx pro5(definently better even then nandub divx3.11)(I did use filters deinterlacer, smoother, 2d cleaner to achieve better, but slowed performance in half). From what I can tell DSF is all thats needed for me to start using it everyday. That last build 5 increased the frame rate 50% in speed and that was without a loss in quality. At the moment I've been digging up all the filter source code I can find, I even used deinterlacers filter with xvid it works, not that great but it definently accelerated it from a older 1.2 version. I'm still digging overlay mixer info its somewhere on this net. I don't know linux, but sometimes they have source code we don't have, or they get code we have but the windows user didnt release. Linux programming goes thru so many spaghetti directions, so it makes it almost impossible to make it reusable for windows. They are using gstreamer to get dxva they have it already before we do.

[trbarry]

chemmajik -

I though an older version of Nic's code was already in CVS. But I don't know the state of it.

I don't know Linux. Are you saying they do have some sort of DXVA-like support somewhere? I'd love to have hardware acceleration but not at the expense of turning over the entire decoding process to M$ software at this stage of the game. If I totally relied on them then I could turn around tomorrow and find they had crippled it with digital rights managment or changed the license or something.

- Tom

[chemmajik]

Found portions of Nics code in a older project mayo filter, but that one uses a closed decore.lib. I've studied some more and I believe the whole decoder would have to be reqritten with the IAM classes to allow DXVA. Or maybe just adding one more output pin using notify maybe all thats needed still investigating. But I'm taking a break for a day brain hurts.

[trbarry]

It looks to me that Microsoft has convinced the video hardware folks to only make the acceleration functions available when Microsoft is totally doing the decoding. But that means they have total control over when standard mpeg4 decoders get supported by hardware.

- Tom