DXVA support possible in ffms2?

[stax76]

Is DXVA support possible in ffms2, how challenging would it be to add it? Do we have smart enough programmers for this task?

[Gser]

Well the thing with DXVA is that it's intent was never for such capturing. Its only one-way so to speak. "Video goes into gpu and out to monitor. It doesn't come back" - to put it in lame-man terms. Hence all processing after decoding is also handled by the GPU.

[stax76]

But then I don't understand how custom presenter renderers can use DXVA, custom presenter doesn't mean drawing the video image with DirectX?

[burfadel]

I guess you could have a Directcompute/OpenCL (or partial) ffms2, but really it would be a component of ffmpeg?... Would be a waste of time bothering with CUDA, since its not a standard and only supports one type of card.

[Gser]

But then I don't understand how custom presenter renderers can use DXVA, custom presenter doesn't mean drawing the video image with DirectX?

Your talking about EVR and this has nothing to do with DirectX.

[Myrsloik]

No, we're all too stupid and untalented for this.

[stax76]

Sorry, I try to ask different:

1) Not possible
2) Too diffcult, too much work
3) No interest
4) other

[TheFluff]

I took a look at adding CUDA support to FFMS2 a while ago and came to the conclusion that it was
a) extremely unportable (not only requiring Windows, but also a certain GPU) and
b) extremely annoying to work with.

DXVA is marginally more portable but is even more annoying than CUDA since it's definitely not intended for general-purpose video processing (i.e. it's ZOMG BLAZING FAST!, but only until you try to read back the decoded video frames to your main RAM; it also has a lot of other annoying limitations on what you can playback and how fast you can do it).

All in all, GPU accelerated video decoding seems like a lot of pain for very little gain and the entire thing smells of a scam. Get a real CPU instead.

[Blue_MiSfit]

For certain annoying corner cases (like as fast as possible 480p h.264 transcoding, or 1080i -> 1080p), GPU decode can be amazingly awesome. It gives a nice bump in speed usually, but isn't a HUGE deal. DGDecNV is pretty sweet though. I'd definitely use it for most cases.

Derek

[stax76]

Does CoreAVC which also supports cuda work with DirectShowSource? It's not frame accurate I know but does it work? Any other alternatives? Maybe somebody already building one secretly?

[Gser]

does coreavc which also supports cuda work with directshowsource? It's not frame accurate i know but does it work? Any other alternatives? Maybe somebody already building one secretly?

dss2.

[Blue_MiSfit]

stax76, I'd guess you're trying to add more comprehensive hardware decode support to StaxRip? Best of luck! Let us know if you discover a way to get GPU decoded video into AviSynth without relying on CUDA / DGDecNV.

Derek

[osgZach]

What about OpenCL?

[TheFluff]

What about OpenCL?

What about it, indeed?
It certainly doesn't have anything to do with GPU accelerated video decoding, because GPU accelerated video decoding doesn't really take place on the actual GPU. What you use for that is a dedicated video decoder chip that does the decoding in hardware (or at least firmware); hence the funny limitations on what you can and cannot playback and how fast you can do it (it has the processing power of a pocket calculator).
CUDA is the same thing really; the fact that it exposes an API to interact with the decoder chip is sort of a coincidence (with the added side effect that it lets you do readbacks of decoded frame data to main memory faster than would otherwise be possible).

If you were to use OpenCL you would have to implement an entire H.264 decoder from scratch in it, and that is not something I'm particularly interested in doing. I'm not even sure it would be possible to do in a sane way given the quirks of how to optimize things for running on GPU's.

[Sharktooth]

OpenDecode. at least for ATI hardware. it will be implemented in the next stream SDK and accessible thru OpenCL.

[communist]

All in all, GPU accelerated video decoding seems like a lot of pain for very little gain and the entire thing smells of a scam. Get a real CPU instead.
It is not a scam at all. My notebook only barely plays AVCHD 1080p25 streams (ffmpeg-mt / nearly 100% CPU usage). But when I play it back with MPC-HC and use AVC DXVA CPU usage drops to ~8-10% and the video is completely smooth.

GPU decoding of AVC streams for Avisynth would be awesome because then the CPU can get to do the real processing work.

Sharktooth do you have any info what hardware will be supported for OpenDecode? Radeons 2x00/3x00/4x00 or only the latest and greatest 5x00 line?

/EDiT:
http://developer.amd.com/GPU/ATISTREAMSDK/Pages/default.aspx

RV6x0 based hardware not supported

[Sharktooth]

4xx0 series support is in beta. maybe on future versions more cards will be supported.

[TheFluff]

It is not a scam at all. My notebook only barely plays AVCHD 1080p25 streams (ffmpeg-mt / nearly 100% CPU usage). But when I play it back with MPC-HC and use AVC DXVA CPU usage drops to ~8-10% and the video is completely smooth.
It's a scam because the situation you describe is the one situation in which it is actually useful (the case where you don't have a real CPU); i.e. it's mostly useful in small plastic toys like cellphones, netbooks and set-top decoder boxes.

Also, in the real world it's drastically less useful than it seems. As I've said repeatedly, it has tons of funny limitations on resolution, framerate, encoding parameters and even metadata flagging in some cases. Certain nVidia GPU's will refuse to decode certain sub-1080p resolutions for no apparent reason, for example.

GPU decoding of AVC streams for Avisynth would be awesome because then the CPU can get to do the real processing work.
Which seems great in theory, but then you realize that now you're bottlenecked on your pocket calculator decoder chip. It's designed for playback, after all, so usually it's impossible to decoder faster than realtime, and unless you're using CUDA you get to spend a lot of time sitting around waiting for decoded frames to be copied from VRAM to main memory.

If you have an actual decent multi-core CPU (like everyone doing HD encodes should have unless they really enjoy waiting) doing decoding on the main CPU is likely to be at least as fast, if not faster, particularly if you're using filtering (which is usually single-threaded, or at least not-very-many-threaded).

The main reason for DGAVCDecNV being NV was (as far as I can tell) that neuron2 was dissatisfied with the level of support ffmpeg devs were willing to give him, not the fact that it was faster.

[communist]

Well it is a Core 2 Duo 2.5GHz (P8700) - so not a real multi-core cpu eh...?

[Guest]

The main reason for DGAVCDecNV being NV was (as far as I can tell) that neuron2 was dissatisfied with the level of support ffmpeg devs were willing to give him, not the fact that it was faster. Not just me, the unresolved trouble tickets affect anybody trying to implement robust and accurate random access. The FFMPEG devs I suppose are happy to make a decoder for players, in which case a few frames off here and there, or skipping a whole open GOP, or whatever, is not a problem, as long as you can start playing clean video within a reasonable number of frames. I can't fault them for that design decision but it does force a search for alternatives if one does not have the time or expertise to fix it personally. Hence the NV and DI lines were created. I hoped for a CoreAVC line for some time, but alas, the needed pieces were never released.

Also, don't forget that NV brings integrated VC1 and MPEG2 allowing the same process and workflow to be used for all the video types. And in some scenarios it can produce a significant increase in the transcoding FPS. Finally, of course, many people find PureVideo deinterlacing to be an attractive time/quality tradeoff.

[TheFluff]

Well it is a Core 2 Duo 2.5GHz (P8700) - so not a real multi-core cpu eh...?

If you can only just barely play 1080p25 on that CPU then you're doing something wrong. Then again that kind of CPU is mostly a toy suitable for office applications and web browsing, and nowhere near enough for sane HD encoding so it doesn't really matter.

[Blue_MiSfit]

Uhh.. a 2.5 GHz Core 2 Duo is not a "toy" at all. That's a fairly rude thing to say...

Regardless, it should be more than capable of playing 1080p25, provided a decent playback chain is being used!

I wouldn't suggest encoding HD on anything less than a quad core CPU (unless you're ok with very high speed / low quality settings), but that's just my two cents.

Derek

[Mounir]

My Pentium 4 3ghz don't complain to rely on GPU decoding for HDTV and the Grey-rays hehe ;)

It seems to me that if one could design a device that tap the output of a graphic card that would be interesting (real time upscaling) , just a thought