HW accellerated encoding with Handbrake

[rs232]

I read up a bit in Internet as I seem to understand this is possible.

Basically, I currently have a 16 core server I use to encode/re-encode into x265.
Despite the device power I still get 6-15/fps while encoding a 1080p video.

I have read that Handbrake now supports hardware accelerated encoding.
Would a NVIDIA GTX1050 or GTX1050Ti work out of the box with handbrake running on Windows10 x64?
Would I see a visible improvement when it comes to fps compared to the 16 core CPU encoding?

Many thanks!

[Bernix]

Hi,
encoding one video with lots of core can hurts quality of final video. Therefore GPU accelerated encoding cant reach CPU (with few cores) quality but is extremely fast. You can use Avidemux <- that for 100% supports GPU accelerated encoding (you can reach around 200fps I suppose). Not sure it is available in handbrake. There is for sure Quicksync.
The quality of video compressed with too much cores was discussed here earlier.

Bernix

[Selur]

a. The problem normally isn't the core count, but the limitation of gpus in regard of what they can do.
b. All consumer hardware encoders I know of (QSV/VCE/NVENC) all use a dedicated encoder chip and not the gpu itself, so the core count isn't interesting at all

[Bernix]

Wiki

HEVC encoding also lacks Sample Adaptive Offset (SAO). Adaptive quantization, look-ahead rate control, adaptive B-frames (H.264 only) and adaptive GOP features were added with the release of Nvidia Video Codec SDK 7. These features rely on CUDA cores for hardware acceleration.

Nvidia Video Codec SDK 8 added Pascal exclusive Weighted Prediction feature (CUDA based). Weighted prediction is not supported if the encode session is configured with B frames (H.264).

So there is close relation between NVENC and cuda cores.

Edit: And how you then describe lower quality encoded on single core and many cores and with GPU? Same content same size?
O.k. I agree they lack of features of cpu h264/265, but also number of cuda cores (higher speed - lower quality)

Bernix

[Selur]

Last time I looked into the SDK the encoding&co was done by the VPU not the cuda core, which explains why even cheap cards with the same VPU have the same encoding and decoding (+/- a few percent for RAM speed) sane the latest modes.

And how you then describe lower quality encoded on single core and many cores and with GPU?

a. Where do you fine a single core gpu ?
b. Problem is that some stuff can't be put that easily and cost efficient into hardware chips (vpus and dedicated encoder chips), you can't do all the fancy stuff you can do with a cpu. A graphic card isn't a miniaturized machine with lots of all purpose processing units where each can do the same as a cpu.
Even if you had the same number of cpu cores with are used by a software encoder as you got processing units in a gpu, the cpu would still win since the algorithms/methods which are designed for cpus can't be simply ported to a gpu. But like I wrote that even isn't the main problem, since the gpu isn't really used, the vpu is.
=> a typical consumer hardware encoder simply lacks the equivalent methods that a software encoder has since the used algorithm can't be ported (easily and cost efficient to hardware).

Cu Selur

[Bernix]

I meant single CPU not GPU. And I agree there is better compression with cpu because of more feature. But also I believe there is same problem in GPU and multiple CPU core encoding. Because of distribution of parts of video. Single cpu sees all frames of video, but multicore systems gets part of video based on what? And this is problem.
And my problem is to describe it properly (language problem).
There is thread about it. If only search engine works for me.

Merry Xmas
Bernix

[Selur]

Yes, you loose some quality if you use more cores (happens on CPUs too), but that quality loss isn't that much.
And yes, most algorithm can't be (easily/efficiently) ported to use lots of slow and limited processing units instead of a few fast processing units. This is the reason why NVIDIA, AMD, Intel all use dedicated vpus&co and not the gpu for encoding. (like I wrote before otherwise the high end flagship cards with way more cuda cores would be way faster than the lower/middle class cards which just have the same vpu,..)

Your argumentation has some merit any explains why gpus are not as efficient as cpus for general purpose computing, but the fact remains that the gpu isn't used
The vpu (a dedicated encoding, decoding,.. chip) is. Thus the argumentation only explains why this is the case.
Currently hardware encoding on AMD/Intel/NVIDIA graphic cards doesn't use OpenCL/CUDA/... (a programming language which allows to use the graphic processing units).
If you check your gpu during encoding you will see that only the VPU is fully used, the gpu isn't used that much.

But using a specialized vpu (like used on normal consumer graphic cards) has it's limits, the vpu is a cheap chip which is really limited in what it can do. Which is why you can't simply add b-frame, 2pass, ... support to NVEnc&Co without new vpu chips which is designed to support this.

Single cpu sees all frames of video, but multicore systems gets part of video based on what?

You could limit this (which partiality is done through lookaheads; even on software based solutions). Also your cpu also doesn't usually look at all the frame at the same time, in 1pass encoding it only seems a 'few' frame around the current frame. (Also note that current encoding algorithms and formats are not frame but block based. ) Looking at all the frame would require to have them all inside your RAM,... bad idea. During 2pass encoding an analysis is done during the 1st pass which allows to avoid bad decisions due to the limited number of frames one can look at during the actual encoding 2nd(/3rd/xth pass), but the point remains even during two pass the algorithms never look at all the frames.

Merry Xmas

To you too.

@rs232: no, the 1050 and the 1050 Ti cards are not supported by NVEnc since their vpu isn't capable to be used by NVEnc.

Cu Selur

Ps.: a lot of confusion regarding CUDA and vpu usage was introduced since NVIDA called their encoders cuda encoders although they never were.

[Bernix]

I will not argue more, but something I have to add. 1050 and 1050ti supports Nvenc. It is based on Nvidia Pascal and yes, it supports Nvenc for both h264 and H265. I own 1050Ti and tested both. Only exception from pascal cards is 1030.
Thats all from me

All Videohelpers have a nice Xmas.

Bernix

[Selur]

Oh, sorry, last thing I read when they came out was that they weren't supported by NVEnc, happy to here that they are.

[sophisticles]

As a point of clarification, on NVIDIA cards, some NVENC features are handled by the CUDA cores, not the encoding chip, if RGB pixel format is used then EVERYTHING is done on the CUDA cores.

This is transparent to the developer, i.e. he/she doesn't need to write any special code to facilitate the hand-off from encoding chip to CUDA cores.

[rs232]

@rs232: no, the 1050 and the 1050 Ti cards are not supported by NVEnc since their vpu isn't capable to be used by NVEnc.

Thanks, is this page relevant?
https://github.com/HandBrake/HandBrake/issues/697

So going back to the OP, as per today, what video card would you suggest to speed up x265 encoding with Handbrake 1.07?

Many thanks

[Selur]

@sophisticles: Thanks for the clarification.
@rs232:

Thanks, is this page relevant?

Only if you plan to buy a AMD graphic card.
From my experience I would rate the quality (not speed) of the encoders in general: software encoder > Intels QSV > NVIDIAs NVEnc > AMDs VCE (no clue about AMDs Vegas graphic cards)

Currently, for consumer hardware encoding, I would either recommend to use one of Intel 'Kaby Lake' CPUs and/or an NVIDIA card with a not down scaled VP8 chip, in example the 1050(ti) cards should be fine. Note that the GeForce GT 1030 and MX150 cards to not support NVEnc (this is what I mixed up in my mind with the 1050 cards before ), since their chip is limited (supports NVDec but not NVEnc, no clue why NVIDIA did this).

Cu Selur

[Bernix]

Hi,
what you quoted was proved is wrong. And yes, handbrake doesn't support Nvenc. If you rely on Handbrake, there is QSV hardware acceleration. It means Intel cpu capabel of QSV and integrated graphics card that supported it.
Link you posted seems they are still waiting for support of AMD acceleration, I can't check it, because I have Nvidia. But there is nothing in option, but QSV.
There are other software solution supports QSV, VCE and Nvenc both 264 and 265.

Bernix

[Selur]

Bernix is right, handbrake probably isn't the best way to go for hardware acceleration if you don't own or plan to buy a Intel CPU with one of the 'Kaby Lake' CPUs.

[rs232]

Understood thanks so it seems like changing the motherboard is the only option if I really want to stick to handbrake.

Thanks for all the info

[Bernix]

There is also possibility to encode multiple video parallel. It can be done in Hybrid. If you dedicate each video 2 threads, so you can do more videos at once. Tested it on 2 videos at once, but maybe with your CPU you can get better results than in handbrake.
But it is not HW acceleration of course. But Hybrid offers NVENC for sure too. But doubt parallel encoding in this case.

Bernix

[Selur]

Encoding multiple movies in parallel with Hybrid using NVEncC works fine here, as long as the card supports it.
I can encoded two HD (1920x1080) clips using NVEncC works without a problem here (GeForce GTX 980Ti), encoding more than that in parallel causes the lastest encode to crash at startup.
-> whether you can encode multiple clips in parallel using NVEncC seems to depend on the capabilities of the vpu

[sophisticles]

I will not argue more, but something I have to add. 1050 and 1050ti supports Nvenc. It is based on Nvidia Pascal and yes, it supports Nvenc for both h264 and H265. I own 1050Ti and tested both. Only exception from pascal cards is 1030.
Thats all from me

All Videohelpers have a nice Xmas.

Bernix

Not only do they support NVENC, they are the only ones in the Pascal family that support 8k encoding. I have tested the GTX1050 Pascal based encoding capabilities and have posted samples in at least 2 threads in this forum. NVIDIA open sources the required headers under an MIT style license that is GPL compatible and NVENC is now included as part of the based ffmpeg framework.

[sophisticles]

Encoding multiple movies in parallel with Hybrid using NVEncC works fine here, as long as the card supports it.
I can encoded two HD (1920x1080) clips using NVEncC works without a problem here (GeForce GTX 980Ti), encoding more than that in parallel causes the lastest encode to crash at startup.
-> whether you can encode multiple clips in parallel using NVEncC seems to depend on the capabilities of the vpu

Consumer gpu's are limited to 2 NVENC instances at any one time; there is one small "loophole" that can be exploited to get around this limitation, NVENC is capable of encoding to multiple resolutions in one go, so if you had a 4k source you could output a 4k, 3k, 2.5k, 1080p and 720p at the same time and it would only count as a single instance of NVENC. Word to the wise, if you're going to try this you better make sure you have a video card with a 4Gb frame buffer because a 2Gb buffer is no were near enough.

The professional Quadro family supports unlimited instances in theory but the practical limits are governed by the amount of available VRAM and CUDA cores.

[Bernix]

Hi sophisticles,
thank you for invaluable information. Is there any free software that is able to do multi-scaling compression you mentioned?
Thank you again.

Bernix

[sophisticles]

FFMPEG is capable of doing it:


http://developer.download.nvidia.com/compute/redist/ffmpeg/1511-patch/FFMPEG-with-NVID...ntu_UG_v01.pdf

https://developer.nvidia.com/ffmpeg

ffmpeg -hwaccel cuvid -c:v h264_cuvid -i <input.mp4> -vf scale_npp=1280:720 -vcodec h264_nvenc <output0.mp4> -vf scale_npp 640:480 -vcodec h264_nvenc <output1.mp4>

If you google around you'll find plenty of examples; I should add that this is really only of use to content producers, i.e. if someone needed to encode different resolutions of the same video for playback on different devices, otherwise I see no reason to encode the same file to different target resolutions.

[rs232]

Ok, after reading all this and more in Internet this is what I worked out:

- My small GT750M uses a chipset able to support HW accelerated h264 encoding only
- I could buy a new video card (willing to) but Handbrake would not use it regardless (right?) as they focus on QuickSync only
- If I am to change GPU I will have to use FFMPEG. I did like Handbrake though because the quick and easy interface, going FFMPEG I would not know where to get started e.g. how to have an auto-crop to remove black bars? Audio,subtitles are 1 click away in handbrake, in FFMPEG it takes ages to tweak all the parameters. Am I missing anything here? Is there perhaps any alternative software/interface for FFMPEG to benefit from GPU accelleration (x265) with easy GUI?

Many thanks

[Bernix]

In avidemux is NVENC 264 and Nvenc Hevc included. But only in way max and average bitrate + what quality. There are in filters also hardcoded subtitles, so it should be easy. But as always, weakness of the program is batch processing. So no problem do things that offer Handbrake, x264 you have all control over settings which is better than in Handbrake, you can also cut out parts of videos no matter where if you re compress video, or without re encoding if starting point is on keyframe.
So many advantages, but not much choices for both Nvenc, and no batch. Of course FFmpeg is best thing, but not GUI to fully use all its features or x264, x265 and NVENC. I'm trying to say, it can handle all options, but you have to know them and write it correctly.

Bernix

[bizzybody]

AVIdemux doesn't batch process and it won't copy soft subs from the source to destination, but it can add them. So you either have to demux them from the source and have AVIdemux add them to each video you run through it - one at a time, or you can use MKVtoolnix or another muxer utility that can copy the soft subs direct from the source files into other files.

Hybrid looks like it may be a tool that can A. use hardware encoding B. do batch processing C. copy soft subs from input files to output files without you having to resort to demuxing or muxing with other tools. I've poked around with it some but it looks more complicated to use than Handbrake, which I found more complicated than VidCoder, which is more complicated to use than AVIdemux.

One wish! NVenc support in Vidcoder OR batch processing and soft sub copy from input to output in AVIdemux. Either one would have me totally satisfied as a way to have video conversion that is both fast and easy to do.

[Bernix]

Just one thing to mention, Handbrake and Vidcoder has horrible AAC codec. It is nowadays most common, so if you are using it, you should also do audio in some other software. For example copy video and just processing audio in Hybrid, or avidemux. Of course you can set high bitrate in Handbrake or vidcoder... somewhere around 160kbps. But when I using it, I let audio pass through and then processing it in avidemux, which has aac(FDK)

Bernix