Transcoding using AMD GPU for hardware acceleration

[vidpro99]

Hey everyone,

I am new to FFAStrans coming from an old telestream/vantage system and wanted to build the same workflows using FFAStrans. I got a workflow working, however I am now trying to do something a bit different. I am trying to do H.264/H.265 using hardware acceleration, specifically an AMD RX580 GPU as it's the only one I have on a personal rig. Has anyone successfully done this before?

I tried a few things in the H.264 custom options textbox field:

-hwaccel auto
-hwaccel h264_cuvid
-hwaccel h264_cuvid -gpu
-c:v libx264
-hwaccel vaapi -threads 16 -vcodec h264_v4l2m2m
-hwaccel vaapi -threads 16 -vcodec h264_cuvid

As soon as a transcode starts, it just stops. Has anyone had any successes doing this? If not, where can I find logs to view ffmpeg errors?

Thanks!

[emcodem]

Hey vidpro99,

welcome to the forum and thank you for using FFAStrans!

Sorry i dont have any practice with amd hardware encoding and i only got an old R9 2xx series card for playing.
My guess is that it works the same as nvidia or quicksync works, so my first working commandline that utilizes the amd hardware encoder looks like this:

Code: Select all

ffmpeg -f lavfi -i mandelbrot -c:v h264_amf c:\temp\test.mp4

Anyway, the general advice for engineering "custom" ffmpeg commands is to first get it working on commandline without using ffastrans at all, and only when you got the command of interest working, you check out how you can transform this command to be used in ffastrans.
For debugging and log viewing, it is best practice to use the webinterface (job details view).

Also, when using unsupported encoders, you have only 2 choices: custom ffmpeg processor or commandline processor. The h.264 processor is bound to use x264 for encoding. This also means that unfortunately you have to deal with all the video and audio transformations on your own. In most scenarios you will end up with a workflow where you can submit e.g. only always the same source file type with same audio configuration.

Lemme know any questions.

[vidpro99]

Thanks emcodem!

I was able to get the web interface up and showing logs. I tried running ffmpeg with h265_amf but windows throws up an error,

Code: Select all

Unknown decoder 'amf_h264'

It looks like ffmpeg already includes "--enable-amf", so I am not sure why I am getting that error now.. I am using ffmpeg that was packaged with FFAStrans. I was able to download AMF but there are no installers. I am not sure where to place the files for it. Though I am fairly certain ffmpeg already includes it and I do not need it.

Any ideas?

[vidpro99]

Update, i got it to work by moving that option over to after the input file. Noob mistake, but otherwise I was able to run it well using a custom ffmpeg node. Thanks so much!

[emcodem]

Yeah, congrats on getting it working!
It would be interesting if you are happy with the results that the AMD hardware encoders deliver in terms of quality/speed and egineering efforts and if you finally really decide to prefer that workflow over the x264 cpu encoding in production!

[FranceBB]

On the other hand, as emcodem said, you would have to deal with every transformation yourself, so it would be your job to deal with frame rate conversion, resizing, colormatrix and primaries conversion etc. This is generally done automatically for you by the filter_builder.a3x, but the encoding nodes don't support any kind of proprietary GPU Encoder like NVEnc or in your case the AMD Enc, however there's an exception: H.264. I noticed that you were trying to insert stuff into the custom x264 params; well those are reserved to the x264 parameters while you were trying to put the ffmpeg commands there. The right option to put there is: opencl=true or simply opencl.
This will trigger the opencl implementation of x264 through the hardware accelerated lookahead. In other words, when you seek frames, those will be stored in the GPU memory and the motion compensation calculations will occur in the GPU and the results will then be passed through to the CPU for the rest of the encoding. Of course, this means that it will be slower than using the proprietary Nvidia encoder or the proprietary AMD encoder, but it will be faster than using CPU only and it will work on any GPU/CPU configuration given that opencl is supported by pretty much everything and the best part is that it will still be using x264 as an encoder so the quality will be higher and the filter builder will automagically take care of everything including deinterlacing, blending, upscale or downscale etc.
I use it on a daily basis and I'm totally fine with it.

[vidpro99]

Thanks FranceBB! Would this work with H265? I got it working with H264 but applying the same settings with H265 doesn't seem to utilize GPU at all..

[FranceBB]

Unfortunately x265 doesn't support opencl hardware acceleration for lookahead and motion compensation. I've been trying to get Multicoreware work on it since its release in 2013, but its work got delayed and delayed and delayed and in the end it never made it through.
It's a shame, really...

(2014: https://forum.doom9.org/showthread.php? ... ost1703362)
(2018: https://forum.doom9.org/showthread.php? ... ost1831624)

And then... Nothing, nothing at all.
Even --opencl code in x264 is abandoned and I had to fight to keep it in there as no one wants to maintain it.
It's sad, really, but apparently this is no longer something that Multicoreware is interested in and that the open source community is working on, despite it being useful.

[emcodem]

no one wants to maintain it.

Well maybe because the amount of work is insane and at the same time the speed difference between CPU only and enabling "opencl" option is not really noticeable?

[FranceBB]

Well maybe because the amount of work is insane

Yeah this is the main reason why Anton Mitrofanov wanted to remove it, but after the public backlash on Doom9, he stopped.
The problem is that he has been very clear: unless someone is gonna pick it up and properly support it, when the time will be inevitable, he will commit this and it's gonna be game over: https://code.videolan.org/videolan/x264 ... est_iid=66

which is why I very much hope that someone will pick it up and maintain it.
But honestly, without Steve Borho (the multicoreware guy), I don't really see the public picking this up and keeping development ongoing...

the speed difference between CPU only and enabling "opencl" option is not really noticeable?

Nah, it is noticeable. It might not be for consumers with GTX or single-encode RTX, but both you and I have servers with Quadro and I can assure you that ever since I started doing several H.264 encodes for videos that end up on socials (Facebook, Instagram, YouTube etc) while the CPU is doing other things, having --opencl turned on speeds things up by a fair amount of fps, especially 'cause the CPU is busy filtering stuff out with Avisynth and other things in my use-cases and having the GPUs work on lookahead really helps.
But yeah, I recognize that for home users that just run 1 encode at a time, maybe even in a not so recent GTX (or maybe even an AMD GPU), sometimes the speed loss caused by transferring frames back and forth in memory among other things makes the actual benefit negligible.
Still, I liked the idea of having --opencl as it's an open standard which works everywhere and it's not platform dependent like CUDA is.
As a matter of fact, you can make use of OpenCl with NVIDIA and AMD/ATI cards along with Intel cards and this is just amazing 'cause it basically means that it's gonna work everywhere.