I'm not sure what part of the forum is best for this post as it's a bit sideways. This video shows a speed test between Quick Sync and NVENC to encode H.265 HEVC from within Handbrake. This may be of interest to anyone using the Pocket or Action, or indeed any DJI camera systems, for encoding their final video masters to H.265 There's also some blurb from my YouTube description below the video. It's a bit of a yawn but there may be some tech info in there that's of some use.
Cheers,
Dave.
Handbrake 4K H.265 video encoder speed test - NVENC v Quick Sync QSV - Intel i9 9900K vs RTX 2080 TI
So what is faster at encoding 4K MP4 H.265 HEVC video files in Handbrake, Intel Quick Sync via the i9 9900K CPU or NVENC via the Nvidia RTX 2080 TI GPU graphics card?
While both NVENC and Quick Sync Video QSV are both faster than software only, one of them is definitely faster than the other.
This test can also been seen as Intel versus NVIDIA, or more precisely, Intel's Quick Sync video encoding technology versus NVIDIA's NVENC video encoding technology. Although both Quick Sync and NVENC are usually just referred to as video encoders. They are both capable of lending themselves to other video post applications.
In the broader scheme of things they can both be used for rendering, decoding, filters and basically fairly much whatever video post processing acceleration and assistance duties that software writers account for within their video post production software and products. But in this instance I'm just concentrating on the task of video encoding within Handbrake.
Just like H.264 before it, H.265, or HEVC, is very taxing on your CPU and/or your GPU for both decoding and encoding. This is mostly due to the complexity of an inter-frame codec, which both H.264 and H.265 are. Despite the similarities, H.265 creates even more drain on your system's resources compared to the already difficult to decode/encode/process H.264. Which basically means that H.265 requires more in the way of raw CPU and/or GPU processing power.
To make matters worse for both codecs, 4K also has to be factored into the equation and quite often up to frame rates of 60FPS and beyond. With the addition of 4K and high frame rates in the equation, it really does compound the technical difficulties and system processing requirements that are needed for encoding and generally any type of work where H.265 is part of the production workflow.
Another thing to bear in mind here is that there are also pure software encoding option for H.264 and H.265. What I mean by pure software, or software only, is a codec, or a specific encoder's codec, that will do all the encoding just with the CPU and not utilise any CPU iGPU like Quick Sync QSV or the AMD equivelent or a dedicated GPU such as those by Nvidia or AMD. There are a number of software encoders available, some of which that are extremely good at encoding very high quality H.265 or H.264 video files. It'd probably be very fair to say that these software encoder solutions can create better encodes compared to QSV or NVENC, especially at the lower bit rates, with the very best probably being the X264 & X265 video encoding engines. But despite the fact that X264 & X265 are probably the best for pure technical video quality, this is only usually noticeable at the lower bit rates or in complex scene structures, such as fast movements within the frame and fast wide changes in chroma and luma content. With increased bit rates the results are usually very similar with regard video picture quality outputs comparing software only such as X264 & X265 and iGPU/GPU assisted ones.
Another thing to bear in mind with software only encodings, even in their fastest modes, they take a long time to complete and can be seriously long if you use higher quality, thorough analysis settings. The one thing that I hope is clear so far is that H.265 can be a serious drain on your resources and that is regardless of the type of encoder used.
Despite the differences in encode times between the NVENC encoder and the Quick Sync encoder. They both offer a very clear and substantial benefit when it comes to encoding times. These benefits will also be seen in any video post production software, and video encoders, that utilise them.
So the last thing to mention are the basic technical details of the files used and generated during the test. The source file was a 4K/UHD 3840x2160 25FPS HQX video file. HQX is a professional intra-frame video production codec that's used by Grass Valley in their excellent Edius NLE, none linear editing software. Although the HQX master intermediate was 10 Bit, the source files that it was rendered from were only 8 Bit. In this instance the last two bits are padded. Both the H.265 files that were encoded by Quick Sync and NVENC were 8 Bit outputs with the the same resolution and frame rate attributes of the HQX master.
fansfe82067d Posted at 9-5 19:39
I'm going to have to come back to this with my brain in gear! It looks like it's going to be very interesting viewing.
Hi.
Although I’m talking a lot it’s mostly just explaining the test setup, the main thing is the bottom line speed of both the results. The extra text info below the video is just a bit of a boring yawn, although some of the info may be helpful for those with an interest in these things.
Quick Sync is available in many Intel CPUs, although some may only be able to encode H.264 and not both with H.265 If you already have an Intel CPU it may be QSV equipped.
If you use graphics card you may already have access to NVENC. Many AMD GPUs also have a similar technology, AMC, it may be worth checking that as well.
Also. You don’t have to pay the extortionate prices of the higher ended NVIDIA cards for NVENC. Their lower priced cards also do this and within any range, 10 series, 20 series, the NVENC encoder appears to be the same through the range.
I’m going to be doing a PC build soon that’s dedicated just to video encoding using all second hand or very cheap components. I’m going to try and find the lowest priced NVIDIA card for that machine that will do high speed NVENC encoding.
Hi David. Thanks for sharing this awesome video that you've created for us. This will really help our valued DJI members here in Forum. Thank you for your continued support!
DJI Gamora Posted at 9-6 08:01
Hi David. Thanks for sharing this awesome video that you've created for us. This will really help our valued DJI members here in Forum. Thank you for your continued support!
Handbrake 4K H.265 video encoder speed test - NVENC v Quick Sync QSV - Intel i9 9900K vs RTX 2080 TI
Hi Dave.
I do have a few questions about this test so here goes.
So what is faster at encoding 4K MP4 H.265 HEVC video files in Handbrake, Intel Quick Sync via the i9 9900K CPU or NVENC via the Nvidia RTX 2080 TI GPU graphics card?
I'm not fully sure why you used handbrake as you normally use Edius. Is it because it is a more widely used program or was there another reason?
While both NVENC and Quick Sync Video QSV are both faster than software only, one of them is definitely faster than the other.
This test can also been seen as Intel versus NVIDIA, or more precisely, Intel's Quick Sync video encoding technology versus NVIDIA's NVENC video encoding technology. Although both Quick Sync and NVENC are usually just referred to as video encoders. They are both capable of lending themselves to other video post applications.
Has NVENC replaced Nvidia's CUDA used on their older GPUs or something else?
In the broader scheme of things they can both be used for rendering, decoding, filters and basically fairly much whatever video post processing acceleration and assistance duties that software writers account for within their video post production software and products. But in this instance I'm just concentrating on the task of video encoding within Handbrake.
I'm assuming because anything else like dealing with effects would make it hard to decide what was going on and which bit of hardware was responsible for which bit of rendering
Just like H.264 before it, H.265, or HEVC, is very taxing on your CPU and/or your GPU for both decoding and encoding. This is mostly due to the complexity of an inter-frame codec, which both H.264 and H.265 are. Despite the similarities, H.265 creates even more drain on your system's resources compared to the already difficult to decode/encode/process H.264. Which basically means that H.265 requires more in the way of raw CPU and/or GPU processing power.
To make matters worse for both codecs, 4K also has to be factored into the equation and quite often up to frame rates of 60FPS and beyond. With the addition of 4K and high frame rates in the equation, it really does compound the technical difficulties and system processing requirements that are needed for encoding and generally any type of work where H.265 is part of the production workflow.
Another thing to bear in mind here is that there are also pure software encoding option for H.264 and H.265. What I mean by pure software, or software only, is a codec, or a specific encoder's codec, that will do all the encoding just with the CPU and not utilise any CPU iGPU like Quick Sync QSV or the AMD equivelent or a dedicated GPU such as those by Nvidia or AMD. There are a number of software encoders available, some of which that are extremely good at encoding very high quality H.265 or H.264 video files. It'd probably be very fair to say that these software encoder solutions can create better encodes compared to QSV or NVENC, especially at the lower bit rates, with the very best probably being the X264 & X265 video encoding engines. But despite the fact that X264 & X265 are probably the best for pure technical video quality, this is only usually noticeable at the lower bit rates or in complex scene structures, such as fast movements within the frame and fast wide changes in chroma and luma content. With increased bit rates the results are usually very similar with regard video picture quality outputs comparing software only such as X264 & X265 and iGPU/GPU assisted ones.
That is one thing I hear a lot. That although GPU/CPU encoding is faster, the finished render is not as clean looking as the better software alternatives. I have not heard the part about it being more noticeable at lower bit rates although the statement seems sound
Another thing to bear in mind with software only encodings, even in their fastest modes, they take a long time to complete and can be seriously long if you use higher quality, thorough analysis settings. The one thing that I hope is clear so far is that H.265 can be a serious drain on your resources and that is regardless of the type of encoder used.
Despite the differences in encode times between the NVENC encoder and the Quick Sync encoder. They both offer a very clear and substantial benefit when it comes to encoding times. These benefits will also be seen in any video post production software, and video encoders, that utilise them.
There certainly are but it also depends on which software is used on what system. I think that is getting harder to predict with certainty as some AMD Ryzen systems seem to be getting better results with some programs than Intel-based machines. The latest Vegas and Magix programs recently did better on a Ryzen based system than other competing programs using H265 encoding which surprised me.
Then there are other considerations such as program responsiveness during post-production that your excellent Edius video showed. If your LNE is slowing down your workflow then a fast render time at the end of a session may not be the most profitable use of a person's time. I confess I find this the hardest part to wrap my head around and figure out.
So the last thing to mention are the basic technical details of the files used and generated during the test. The source file was a 4K/UHD 3840x2160 25FPS HQX video file. HQX is a professional intra-frame video production codec that's used by Grass Valley in their excellent Edius NLE, none linear editing software. Although the HQX master intermediate was 10 Bit, the source files that it was rendered from were only 8 Bit. In this instance the last two bits are padded. Both the H.265 files that were encoded by Quick Sync and NVENC were 8 Bit outputs with the the same resolution and frame rate attributes of the HQX master.
So the source files are the ones normally used within Edius when editing and not exported or the original video files? Not normally readable outside of an Editing program? I'm sorry for these additional questions but as I'm currently thinking about upgrading my system I'm trying to do the best I can within my budget and want to take in all relavent information.
Ray-CubeAce Posted at 9-7 07:31
Handbrake 4K H.265 video encoder speed test - NVENC v Quick Sync QSV - Intel i9 9900K vs RTX 2080 TI
Hi Dave.
Hi Ray,
Here’s the answers to your questions.
1. I’ve used Handbrake as it’s free and means everyone has access to it. It’s also a great UI for a number of encoders, including X264/5, can be further augmented with CLI parameters and is FFMPEG based. With Edius and as great as it is, it doesn’t encode to H.265 unless you’re on version 9 and even then you have to the right Intel CPU, it also doesn’t use NVENC.
2. CUDA is actually part of the core processing and NVENC is a separate thing, it’s more like an instruction set for the core technology. You can think of it like a DSP that’s got a very limited skill set but does it very fast, much faster than a CPU which is designed for many tasks. I don’t think the GPU processing is segmented, I think it’s dynamic. I only say this because NVENC performance is effected by whatever else the GPU is doing, game play as an example. If a game is maxing the GPU then NVENC will suffer and the other way round. On the other hand with Intel, QSV is a dedicated co-processor that sits on the die with the CPU etc. Regardless of how hard the CPU is being pushed, QSV will still do what it does, it is a function of the iGPU and as such is only effected as in as much a dedicated GPU would be by the CPU being pushed.
3. This question is asking something beyond just encoding, my example was just encoding. But if using other tasks that use the GPU at the sims time, as per your question, answer 2 would apply.
4. With respect to software vs hardware encoding, CPU v GPU. I’ve been working professionally with both audio and video for about 30 years. During this time I’ve done many things with video production including having one of the first independent DVD authoring and mastering facilities in the UK and I also had one of the first free to view video video streaming platforms in the UK about 25 years ago. I’ve worked with high end video encoding all that time and seen many codecs come and go and seen some get better. During that time I’ve built and maintained many systems, developed encoding/production workflows for many situations, including a post workflow for our old indie film company and have ran more tests on stressing codecs than most people have had hot dinners I can say with absolute authority that software encoding with the right codec is always better, especially at low bit rates. The best encoding technology I’ve come across is X264/X265. I’ll do an example and video soon with some native Pocket UHD 59.94 source files that clearly show the difference.
5. With respect to AMD. Their AMC technology is quite flawed and doesn’t stand up well to even QSV as a pure encoder. With respect to how their GPUs and iGPUs work in the wider aspect of post, they’re better than Intel’s iGPUs but not as thought out as Nvidia’s. Although they do beat Nvidia very easily on cost to performance. All things being equal, optimised host software and platform etc. I’d say that AMD come out on top due the scaling of performance for cost. Although the industry generally favours Nvidia. With regard to performance with any particular NLE or post app, again it’s down to if the manufacturer has optimised well for a particular GPU technology. For instance and as I mentioned earlier, Edius won’t encode with Nvidia but will use it decode certain codecs and then won’t use it for most effects but will use if for a couple, like its primary colour corrector.
6. Yes, my intermediate is HQX and not the source files. HQX is in my opinion the best rec.709 codec up to 10 Bit, 4:2:2 and 4K. It’s obviously also intra-frame. With the settings that I use for my master export from my Action and Pocket’s 8 Bit 4:2:0 inter-frame source files, I get a master that’s visually indistinguishable from the sources but has the advantage of much better transportability and manipulation further down the production pipeline. The HQX codec can be downloaded from the Grass Valley website and can be seen many other post applications for decode and encode and it’s also got an associated filter within FFMPEG.
Hope this answered your questions, better go an lay down now and give my noodle a rest
Thank you for the detailed explanation, David.
Most helpful and a lot to look up and digest.
That at least has consolidated my feelings about AMD and has made me think more about GPUs and possibly what to look for if I decide to need one after my preliminary build.
As GPUs to my mind, seem more designed with gaming in mind than video production which I have never done since the first release of Helicopter Gunship, what would be considered overkill for video work up to 4K?
At what price point can I get something that would work well but not be overkill? I ask because NLE designers are already getting ready for 8K and I'll probably never get into video production of that quality within my lifetime.
Ray-CubeAce Posted at 9-7 17:23
Thank you for the detailed explanation, David.
Most helpful and a lot to look up and digest.
That at least has consolidated my feelings about AMD and has made me think more about GPUs and possibly what to look for if I decide to need one after my preliminary build.
Hi Ray.
The problem with GPUs is that it is really like ‘how long is a piece of string’. There’s really no guessing what certain GPUs will be like with different apps, it’s mostly a case of trial and error.
Sorry I can’t be more helpful but I’ve always found that the differences with these things are far too much.
As a for instance. I’ve just done a test with a 2GB GT 710, it’s a £30 basic Nvidia card. While it’s not supposed to support NVENC, or at least it was disabled in the drivers and you needed to do a register mod to make it work, it will happily do H.264 in Handbrake. It’s actually faster at H.264 than what the i9 is at H.265. Go figure????
As a rule of thumb. A second hand GTX 1080 Ti will be extremely good and not far behind a RTX 2080 Ti with most video post applications but will cost at least half the price.
I’ve just ordered a GTX 1660, it’s the cheapest proper Turing card but no RTX etc, I’ll be testing it for various stuff. There’s a GTX 1650, although it’s Turng based it uses the previous NVENC encoder not the V2 that usually comes with the Turing cards.
The problem with GPUs is that it is really like ‘how long is a piece of string’. There’s really no guessing what certain GPUs will be like with different apps, it’s mostly a case of trial and error.
Hi David.
Interesting you should mention a GTX 1660 and the guessing game about which bit of hardware tackles what problem.
Have a look at this.
Here is a google translation of an article from Videoaktiv online magazine where a Magix Product owner-developer Florian Liepold discusses the new Infusion Engine in MEP2020.
Q. The infusion engine should be up to 5.8x faster - in which process did you measure that or in which processes does the new infusion engine bring benefits?
A.The infusion engine is a radical remodeling of our import to support DirectX 11 textures. In simple terms, the way image data is stored and transported in the program has been fundamentally re-implemented.
The transfer of the decoded images in the subsequent processing chain is done on the shortest path, because they do not leave the memory of the graphics card and previous copying omitted. Decoding and processing merge, so to speak, for maximum throughput.
The greatest benefit comes in applications where many image data are moved. Multi-track projects, multicam editing, as well as the use of video-based templates, such as collages from the in-app store, benefit greatly.
Unlike in the past, we now use the graphics card for the import by default. That alone will give a noticeable boost to users who may not have known this attitude.
In addition, we have carried out targeted optimization in the area of effects. Lookup tables are now calculated as multicore and SSE optimized. Horizon straightening is GPU-accelerated, and customizations to internal processing levels such as buffers and GPU uploads are dramatic in many situations. And all without compromising on the quality of the presentation in full 16-bit Deep Color color depth.
This is particularly noticeable in picture collages, for example. These use many effects in combination and were often not fluid playable. Now it's even possible to insert videos into collages and play them for the first time without preview rendering in real time.
A typical multitrack test project consists of a cascade of AVCHD or HEVC FullHD videos, which increase the utilization in a semi-transparent manner or as a picture-in-picture arrangement. In order to make it more realistic, the project also contains parts with only one video track but, for example, title overlays. It is about simulating different load situations that can occur in customer projects.
We now use an internal benchmark to measure the average frames per second across the project. The program shows the project as fast as possible. The test system for the speed factor consisted of an AMD Threadripper 1920X and NVidia GeForce GTX 1060 6GB. The test included Video Pro X (version 10) and a beta version of Video Pro X 11. It measured a jump from an average of 25 FPS to 147 FPS over a test project.
From what I understand from this and other info from Magix and my own observations is that for a multiple GPU system the program decides which GPU to use for which task. So for instance the decoding for playback of HEVC appears to be pushed to the main GPU part of the Nvidia card when the discreet card is selected in the Display Options, whereas H.264 is decoded only on the iGPU. When Display is set to use the iGPU it appears to do both H.265 and H.264 on the iGPU.
The new engine appears to be mainly about accelerated preview of the timeline and I think we should not expect any leaps in export encoding speeds
During the H.265 HW encoding for export, the program is supposed to automatically select the Nvidia card and use its' separate hardware Nvenc chip, whereas H.264 can only use the QuickSync hardware layer embedded in the iGpu of the Intel processors. If a discreet (Nvidia) card is not present the H.265 (HEVC) HWA export is accomplished on the iGPU.
"I had read on the forums here I think, that using hardware acceleration produces a rougher looking final render if trying to use H265 at higher quality levels and is only useful for H265. Am I right in thinking that?"
You are right in that hardware encoding by either the Nvenc chip or the Quicksync HW layer will produce a rougher export file as some optimisations of the encoding are left out at any quality level set, but this seems minimal to me and I am fairly critical. Besides HWA seems essential for H.265 because a SW render is so g..dam slow with this codec.
The good thing about this is that Magix are not concentrating all the improvements around the Intel processors giving users without iGPUs the benefits of improvements in playback and handling during the edit with the new Infusion engine, alongside the capability for HWA export of H.265 via Nvidia cards.
----------------------------------------------------------------------------------------------------------------------------------------------------
It's interesting to see how these people think and implement their software. Note the card used for testing.
Second Officer
First Officer
Captain
Administrator
lvl.4
.
