Log in

View Full Version : Cuda Challenge for x264 ... ?


Pages : 1 2 [3]

ExSport
17th February 2010, 22:58
Maybe you don't understand me:)
My question is if decoding part can be done via CUDA or DXVA and then decoded frames feeded to mpeg2/x264 encoders so if it will be faster and if it is possible.
I suppose that encoder needs to decode frame before it can be encoded so why not to use CUDA or DXVA for it and not slower "decoder" implemented in mpeg2/x264 encoders.
Is this technique possible?
As I already said I tested mencoder with loaded Coreavc driver and some encodings were faster, some slower.
I suppose it is because when MEncoder used internal decoder, CPU was used at max but when combination of CoreAVC+MEncoder used, CPU was used between 15-70%
So result was at best case 25% faster(encoding) with CoreAVC(Cuda enabled) for full movie(CPU usage about 70% in average) but sometimes speed was same or slower when CPU was used fewer. Don't know why so big differences(why CPU is not used at max when CUDA+MEncoder used but 100% used when internal decoder used)...
Many thanks for answer

Snowknight26
17th February 2010, 23:13
CPU usage doesn't imply speed, so estimates are invalid.

RunningSkittle
17th February 2010, 23:16
...decoding part can be done via CUDA or DXVA and then decoded frames [fed] to mpeg2/x264 encoders so if it will be faster and if it is possible....

yes its possible and can already be done via avisynth or mplayer (with patches), however AFAIK there is not a standard way to accomplish this across different platforms. Fortunately x264 accepts input from avisynth on windows and yuv4mpeg for piping from mplayer :)

LoRd_MuldeR
17th February 2010, 23:19
Maybe you don't understand me:)

I think I did. But it seems you didn't understand the answer ;)

My question is if decoding part can be done via CUDA or DXVA and then decoded frames feeded to mpeg2/x264 encoders so if it will be faster and if it is possible.

As I already said, decoding a H.264 source in "hardware" and then sending it to the (software) encoder is possible indeed. And there already are solutions for that!

But DXVA cannot do it. DXVA is playback only. DXVA decoders are coupled to a DXVA-enabled renderer. Once the encoded bit-stream is sent to the renderer by the DXVA decoder, the frames will be decoded in hardware and then outputted directly to the screen. The software cannot get the decoded frames back. That's why DXVA isn't suitable for re-encoding tasks.

Furthermore there is no need to implement a H.264 decoder in CUDA, because there already is a dedicated H.264 decoder hardware on your graphic's card. CUDA allows you to run general purpose computations on the GPU. But implementing a H.264 encoder on the GPU (via CUDA) will never be as fast/efficient as using a dedicated decoder chip. And that chip is present on any halfway up-to-date graphics card!

There are several ways to access the H.264 decoder hardware on your graphics card in a way that allows feeding the decoded frames into x264 (or a similar encoder). These include at least DirectShowSource+CoreAVC and DGAVCIndexNV. To make this clear again: Both, CoreAVC and DGAVCIndexNV, do not implement a H.264 decoder in CUDA. Instead they use the "CUDA Video API" (CUVID) to access the dedicated H.264 decoder chip on the graphics card. In contrast to DXVA, CUVID has the advantage that you can get the decoded frames back and process them in software, such as a software encoder...

CPU usage doesn't imply speed

Very true.

jakor
18th February 2010, 00:16
But DXVA cannot do it. DXVA is playback only. DXVA decoders are coupled to a DXVA-enabled renderer. Once the encoded bit-stream is sent to the renderer by the DXVA decoder, the frames will be decoded in hardware and then outputted directly to the screen. The software cannot get the decoded frames back. That's why DXVA isn't suitable for re-encoding tasks.

actually - this is not correct. By implementing a custom renderer it is possible to retrieve raw data from decoded frames from DXVA. True, that with CUDA interface it is a little bit easier to implement, but DXVA architecture looks to me like more robust ;-) and not dependent on NVIDIA.

ExSport
18th February 2010, 00:36
Thanks for answers:)
I know that CPU usage doesn't imply speed but that maybe because CPU wasn't always fully used when Coreavc+Mencoder used so MEncoder alone with 100% CPU usage was more efficient but when combination of both used CPU 70% in average, encoding was faster about 25%.
So lower CPU usage and faster encoding:-) But unfortunately for some movies usage was lower so MENcoder alone was more efficient.
About AviSynth I know I can use it but I tried to don't use it and get rid of codecs mess. MEncoder alone(with CoreAVC loaded) has an advance that no installed codec is needed, no configuration etc.
Now I understand that DXVA is useless for me because I need to do realtime encoding of h264 to MPEG2/x264 and now I know it is not possible with DXVA but with CUDA yes.:rolleyes:
So only solution for me is Sherpya MEncoder+CoreAVC with CUDA enabled. But bad thing is that results are not stable so sometimes speedup is 25%, sometimes is slower. I thought that when decoding of 1080p file will be done in HW, there will be more cycles for encoding process in MEncoder and it is true but only partly, not for all files :mad:
My concern is PS3MediaServer. It is DLNA server and on slower PC or when more HD files have to be transcoded(MPEG2), every cycle for encoding part is a win. It is difference if realtime encoding will be 21fps or 26fps = difference of possibility of realtime streaming to any rendererer, not only PS3 with DLNA server:cool:
So again many thanks for useful info
Now I know that implementing experimental ffdshow with DXVA is not right way for multithreaded MEncoder which I use.

kypec
18th February 2010, 09:08
About AviSynth I know I can use it but I tried to don't use it and get rid of codecs mess. MEncoder alone(with CoreAVC loaded) has an advance that no installed codec is needed, no configuration etc.
Avisynth has nothing to do with installation of codec-packs. There's absolutely no need to install anything but DGAVCDecodeNV (very low-cost payware) if you want to use GPU accelerated video decoding in your avisynth scripts (provided you have nVidia card with integrated VP2+ chip of course).

ExSport
18th February 2010, 15:49
To my knowlede when you want to use AviSynth "encoding" with MEncoder, you need installed codecs in system because codecs are used for decoding part and then it is feeded to MEncoder.
But without AviSynth = MEncoder alone I can use integrated decoders with no "background" influence or mess in codecs configuration. I suppose when AC3filter will be configured to STEREO only, you can't encode it then in original 5.1 audio. Also missing codecs will terminate encoding process because it will fail with AviSynth but not with MEncoder alone with all intergrated decoders/encoders.
Also DGAVCDecodeNV is not multiplatform so it is not well usable with java PS3MediaServer which works on OSX,WIN,Linux etc.
Anyway many :thanks:

LoRd_MuldeR
18th February 2010, 20:12
actually - this is not correct. By implementing a custom renderer it is possible to retrieve raw data from decoded frames from DXVA

Well, that sounds interesting. But so far I have not seen any project that implemented a custom renderer for DXVA to get the decoded frames back into main memory.

So is this just some hypothetical idea or has this actually been proven to work? Any project names?

True, that with CUDA interface it is a little bit easier to implement, but DXVA architecture looks to me like more robust ;-) and not dependent on NVIDIA.

DXVA is extremely pick with what streams it accepts (regarding levels/profiles), CUVID is not! CoreAVC with "CUDA Decoding" even handles 1080p at encoded 50 MBit/s with all x264 settings maxed out.

So I'd say CUVID is much more "robust" than DXVA. But yes, CUVID has the major drawback that it's a proprietary interface available only on NVidia hardware...

jakor
19th February 2010, 00:33
I've made a small project - decoded video stream on DXVA hardware and got frames back and dumped them to HDD.

DXVA is extremely pick with what streams it accepts (regarding levels/profiles), CUVID is not! CoreAVC with "CUDA Decoding" even handles 1080p at encoded 50 MBit/s with all x264 settings maxed out.

So I'd say CUVID is much more "robust" than DXVA.
having said beforehand that it is still the same dedicated VP2 chip how does it make sense ?
1.5 years ago I implemented both DXVA and CUDA H.264 decoders - and yes, programming with CUDA interface was much more fun, it was more controllable while DXVA pain in the ass to figure out which flags mean what in their input structure, but being able to run them both DXVA ran more smoothly, while CUDA stuff had crashes here and there. Maybe it was raw drivers - it was early time adoption and now it works as solid as DXVA, but proprietary thing is not good and can not be relied upon - one day they release driver version without CUDA support and what do we do ? While disabling DXVA support would be a tougher thing to do (from marketing and licensing point of view).
However ATI liked to exclude a lot of DXVA supported streams with newer catalysts, so it can not be trusted either ;-)

alexcyn
28th April 2011, 07:35
Well, that sounds interesting. But so far I have not seen any project that implemented a custom renderer for DXVA to get the decoded frames back into main memory.
So is this just some hypothetical idea or has this actually been proven to work? Any project names?

In DXVA2 (Vista and Win7 only) this is possible without any renderer. I did this in some feasibility study myself in simple console app - decoded mpeg2 stream and received YV12 raw YUV frames back. Have no idea about performance, though some people say that large transfers from graphics card back to PC are much slower than other direction.
In new AMD APP SDK they claim that DXVA decoded buffers are available for OpenCl app.
=Alexey

roozhou
28th April 2011, 10:17
In DXVA2 (Vista and Win7 only) this is possible without any renderer. I did this in some feasibility study myself in simple console app - decoded mpeg2 stream and received YV12 raw YUV frames back. Have no idea about performance, though some people say that large transfers from graphics card back to PC are much slower than other direction.
In new AMD APP SDK they claim that DXVA decoded buffers are available for OpenCl app.
=Alexey
Hi, how did you get YV12 frames back? Shouldn't it be NV12?