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. ------------------------------------------------------------------------------ Please consider supporting my TH-cam channel by liking, subscribing and clicking the bell icon for notification of future videos. It really does make a big difference and also please share my video links. Or use my Amazon affiliate links when purchasing from Amazon, I receive a commission that helps my channel. www.amazon.com/shop/davidharry www.amazon.co.uk/shop/davidharry Thank you very much for watching this video, take care and goodbye now. Cheers, Dave.
David! Why do you use Handbrake? It is very bbackward software with few options. Moreover, it does'nt use the in-card compression technology, where the video data is not copied to the system memory during compression and back to the card etc... You can achieve better performance and quality if you use more sofisticated software like the Hybrid . You can find Hybrid at Selur.de
@@Celebrate81 ok i just did try your suggestion , that hybrid don't even support h.265 in qsv or nvenc so i don't see how it can be considered superior to handbrake while its missing a key feature that is very important
Would have been SUPER helpful to see file sizes of the outputs.... Surprised that needs mentioning. Second, would have been SUPER helpful to see if there is any noticeable difference in quality of the video playback between originals and the 2 new versions.
In regards to my own NVENC testing. If everything is the same as your CPU HEVC except the encoder that was selected than you're looking at 2-3 times the file size of the CPU encoded file to have roughly similar quality.
@@GoatZilla As I’ve already said, the video was strictly dealing with a “speed” test nothing else. There are a whole number of other things such as very specific encode parameters used etc. That could also have been mentioned, but where do you stop and draw the line between what the video is specifically about and other extra information. Trying to cover all bases for what else may be asked from any such test is just going to result in a much longer video that de-focus from the main point. Plus the big issue with the request for file size, is that this will only have a bearing on this exact encode, it will have nothing to do with any other encode. Cheers, Dave.
Hi Al. The idea was to keep the video short plus it’s difficult to do certain comparisons due to the extra encoding that TH-cam applies. Keep an eye on my channel as I will be doing a video comparison where I will link to a couple of download files so people can see the differences properly. Cheers, Dave.
Hi Péter. What you’ve said is completely wrong. Handbrake is only a GUI that controls various codecs and in this video it’s only used to control the hardware, handbrake itself is not doing the encoding. Even in software mode what you’ve said is wrong as well, as the encoding is done by X264/X265 etc. again not by handbrake itself. Cheers, Dave.
@@DavidHarryI want to encoder my gopro video for H265 + which configuration is batter for me Intel core i7 9700k with 630hd or amd ryzen 7 2700 with nvidia gtx 1660 thanks
Hi. Between all three encoding methods, Nvidia/NVENC, Intel/QSV and AMD/AMF, NVENC is the best. At higher bit rates, NVENC and QSV will both look very good, AMF can sometimes have problems and doesn’t look as good even at high bit rates. At lower bitrates you will notice that NVENC will produce a better looking encode. At any bitrate or picture complexity, NVENC is also the fastest. The GTX 1660 will produce the exact same picture quality as a RTX 2080 ti and will be just as fast, they both use the same encoding engine. I hope this helps. Cheers, Dave.
Placebo is not a better quality, it's more like an experimental feature, that actually does the opposite sometimes, the size of file increases and quality might be the same as slow, and FPS is very very low....
Hi David, you say the quality difference between x.265 and H.265 NVENC is small at high bit rates. What rate you consider a high bit rate? I have been encoding UHD full length movies in x.265 at 9000 kb/s and it takes about 2 days to encode with a i7-9900k, or 1 day with dual Xeon 6146's, but I recently tried H.265 NVENC on a UHD movie and it only took 2 hours. I thought that 9,000 kb/s was high, but you used 100,000 kb/s. I never dreamed anyone would actually consider using a value that high. At what bitrate does the quality difference become minimal, because man, I would really like to start using NVENC on everything due to the speed increase.
Hi Thomas. Great question, thanks for asking. The bit rate will all depend on the source material. If for instance you started off with uncompressed video, such as a film/studio master, then you can go to relatively low bit rates as the master would have contained very high picture quality such as colour, resolution, bit depth etc. Such masters will be using an intra-frame codec, basically a codec that uses unique and individually encoded stills for each picture, also called I frames. Then there's motion properties to consider, fast movement within the frame or fast movement of the camera. But because the master will have been of such high quality, it can handle being encoded to low bit rates using a destructive codec such as H.264 or H.265, which will throw away a lot of the information from the master but can still look awesome. If your source material is something that's already been heavily compressed, for instance camera footage using H.264 or H265 or maybe ripped movies. This footage may well look great but will have been encoded very heavily using the inter-frame encoding method. Basically only a few frames in every second are unique, although still heavily compressed, these are I frames and the other frames, predictive and bi-directional, P&B frames, are frames made up one way or another with information taken from that point in time from the original source or a lot of information from adjacent frames. This method of redundant encoding can look awesome but it is none the less heavily compressed, so when encoding from a source like this you are compounding encoding artefacts from one heavily compressed/destructive encode to another. In this instance a higher bit rate is necessary to maintain quality due to the compounding encoding/codec effects of using a heavily compressed inter-frame codec. I know what I've just explained is an over simplified version of what goes on and there other factors to consider but that simple explanation is good overview. While 100,000Kb/s may sound very high, it is in fact very small when compared to an uncompressed master of the same material. I used 100,000Kb/s in this example as it is what I use for own TH-cam uploads. I use this bit rate as my camera footage is either H.264 or H.265 and is already heavily compressed before I edit and re-encode it and I need to maintain as much of that quality when I export my final edit at UHD/4K 25FPS, because after that, TH-cam then re-encodes it further and will effect the quality even further. If you have a skim through my TH-cam videos and watch the UHD/4K versions, most of the footage holds up quite well and still looks sharp etc. I'm gonna start a game type channel in a couple of months showing various tech stuff to do with gaming and various things such as Android and console stuff etc. I've already got a few examples of some walk throughs and game play there. Take a look at this stuff in UHD/4K. As it's 60 FPS, some of the stuff is uploaded at 200Mb/s (200,000Kb/s) th-cam.com/channels/4XX0WWrHCObF36PWsmCj7Q.htmlvideos Getting back to your scenario with NVENC & X265. No matter what you encode you will always destroy picture information, this can be lessened with high bit rates, or longer more involved encodes such as using certain options with X265. There is always a practical trade off with encoding, speed vs quality vs size. There's no doubt that X265 and X264 are the best encoding methods for both the H.265 and H.264 codecs with regard picture quality and size but it does come at the cost of speed. Out of all the GPU assisted methods of encoding, my tests have shown NVENC to be the best and also the fastest. For your personal use I think using X265 and waiting a day or longer is probably proper boring and impractical. If I were you I'd just use NVENC and pick the lowest bit rate or Q rate that you are happy with for quality and final file size and encode at a fraction of the time. Like I said, encoding involves many trade offs but it's always best to use what's best for you and your encoding setup. One thing I would say though and bear in mind I've worked in audio production for over 30 years and video production for over 25 years and used to author VCD using MPEG1 and I'm always looking for the best possible quality. I wouldn't recommend chasing the CPU route and buying more expensive multi core CPUs so you could speed up X265, I'd simply find the quality you'd be happiest with with NVENC and benefit from the speed and lower cost. Don't forget a GTX 1660 will encode just as fast as a RTX 2020 as they both use the same NVENC encoder but the GTX 1660 is a fraction of the price of a RTX 2020 and much cheaper than high core count multi-core CPU. NVENC has gotten better and better over time and I'd guess that will carry on and maybe one day X265 may be able to be accelerated with the same great quality but much faster using CUDA or NVENC. Anyway. I hope this reply has helped, I'll have to get off now as my encode for today's TH-cam upload has just finished on HandBrake using NVENC at 100,000Kb/s for my UHD/4K TH-cam master file. Now the boring part, uploading a 9GB file to TH-cam on a internet connection over 4G on my phone :) Cheers, Dave.
This video would have been more relevant if the resultant file sizes were compared, and a brief review on whether the final video was of acceptable quality or not... just my 2 cents.
The point that is missing here is how big the output files are, most of the times with qsv the encoded file ends up being bigger than the original one!
No, the point being missed here by you and many others is that this is a speed test, it says so in the title. The title doesn’t say quality or size, it says speed test and if you don’t know why QSV is producing larger files than the source then you really need to understand that before questioning other things that you obviously don’t understand.
@@DavidHarry no man, you clearly said you wanted to preserve quality, and file size is clearly as important, you just missed it and it would have taken nothing.. great video btw
In general same quality but withj a file 2 tiems bigger for nvenc. So nvenc gives in reality 2 times less quality (at same bitrate). That is why I do not use it.
Good to see that someone knows how to calculate the size. I really don’t understand why people take the time asking certain questions when it’d be much easier just getting a calculator or if they don’t know the difference between bits and bytes, just Google it. 100000x548÷1024÷8 Cheers, Dave
Hi. At such high bitrates there won’t be much visual difference between any two different encoders. It’s at low bitrates where better encoders will be visually and technically noticeable better. I’ll do a video soon using QuickSync, NVENC and X265 at low bitrates for quality testing, this test will have downloadable files. Cheers, Dave.
Hi David. I appreciate you running the comparison, but I have some questions. What was the final file size for each? What is your opinion of the final quality for each? How long does it take to do the same encode without either HW acceleration using the i9-9900? What is that file size? How does that quality compare? Thank you!
I am weighing a i9-9900 vs R9 3900x build. I do a lot of long 4k High school sports video encodes. I am always trying to minimize encode time and file size without giving up too much quality. I have experimented with NVENC, but do not get the same quality vs file size on my GTX970 as in software on an aging i7-2600K. The i7-2600K supposedly has the first generation of QuickSync that supports h.264, but not H.265. However, Handbrake doesn't appear to support QuickSync for i7-2600K so haven't tried it.
@@davidbaldwin3407 would be difficult to use AMD's version of quicksync, not sure if it's supported any more. 3900x might faster in straight CPU encode though thanks to additional cores
Hi Donovan. Unfortunately no, not yet. All my camera stuff is only 8bit rec709 and the same with any of the game capture stuff. I may be changing cameras at the end of the year, so will be doing HDR stuff then and I may start doing some HDR game stuff as well, as I can edit and view HDR. Cheers, Dave.
hmm your orig file was 1536 kbps so why would you want to encode at 100,000 kbps? just curious as i have no idea how all this works? also you showed info on the file before encoding but not after ie file sizes and bitrate it actually is now? I would assume the file size was bigger then when you started if it works how i think it does? I have no idea on this stuff and its why I am asking.
Hi James. As per the title, this was a speed test. As such, attributes such as file size and quality didn’t matter as neither would make any difference to the outcome of this particular test. Changing parameters such as encode quality for the output during the test would make a difference to output quality when combined with bitrate and would also change the speed of the encoding. However, as certain parameters were set as a constant, it was the best way to make a comparative measurement for the speed. Cheers, Dave.
@@DavidHarry but wouldn't a more normal bitrate also make it go faster to? ie if your encoding for speed you still wouldn't want to encode at higher bitrate then what it already is as that might slow it down to wouldn't it? Ie couldn't it take longer for one of the ones you tested go faster at bitrate you would actually do it at etc? Like i said i have no idea just asking really as trying to learn this stuff to convert some stuff myself. Thanks.
Hi James. No, not with this setup. You’ll find most encoders, especially hardware encoders which is what’s being used in this test, won’t change the speed when changing the output bitrate. In fact, I don’t think I’ve come across any software encoders that would change the speed either. The only reason why the bit rate was what it was, is because this is one of my usual bitrates for my own TH-cam uploads. You have to remember, this video and the way that I would create a TH-cam, aren’t being done for the best quality at the lowest bitrate. When making an encode to be the best at the smallest sizes/bitrates, you’d use different encode parameters to make that happen but your encode would take a lot longer. However, if you don’t need small files that take ages to do, then large fast files are more appropriate. In certain instances, it would take me longer to make a small/slow file and upload to TH-cam, compared to a fast large file and upload that to TH-cam. This is because my upload speed will be faster than the time taken to make a slow/small encode, so fast large file makes it quicker to get the whole TH-cam upload done. Don’t forget, when you make an exhaustive slow encode at a low bitrate, it won’t look any better than a fast encode at a high bitrate. If you are interested in encoding, I’ve done many types of encoder tests on my channel. I will also be doing some more soon and some specifically for slow low bitrate. With the quality slow tests I will also be including some download files, because it’s pointless showing a slow encode on TH-cam as TH-cam only re-encodes the file and makes it worse, so you still never see what the original file was like, which is why I’ll be including downloads. In fact, you’ll find some of my previous tests have downloads as well. What type of stuff is it that you are encoding? Cheers, Dave.
On both of these you can choose your quality in the lower left. Instead of using fast, medium, or slow, choose high quality. Also, choose a higher bitrate.
Hi. If using high bitrates you’d be hard pushed to see any differences between the two. If using low bitrates and setting both encoders to their best quality encode settings you will see that NVENC produces a better looking picture. If you want the absolute best possible quality, using X265, which is the software encoder, will produce the best quality at low bitrates. Although, to do this you have to use its slow settings and the encodes are very slow even on a multi core CPU. I may actually do that test as it is interesting and give downloadable examples. Cheers, Dave.
@@TabalugaDragon That was true some time ago. However if you have tried the latest Intel Quick Sync on Coffee Lake or Turing/RTX 2080's NVENC, you will find it handily beating x264 and x265 in quality as well as speed. Which is what I was asking for confirmation but then I got these latest GPUs and confirmed it myself. See here also: unrealaussies.com/tech/nvenc-x264-quicksync-qsv-vp9-av1/
How much is the CPU used while encoding with NVENC? I'm contemplating getting a new turing card but my CPU is weak so I'm not sure if I'll need a CPU upgrade or not.
Hi Bryan. The CPU doesn’t matter, the GPU does all the encoding. If it’s mostly encoding you’ll need the GPU for, the GTX 1660 is a great card, it will encode just as fast as the RTX 2080 ti. Cheers, Dave.
Hi Andrea. In this instance Handbrake isn't an encoder, it's just controlling the encoders for NVENC and QuickSync. Even in software encoding Handbrake still isn't the encoder, it would then be just an interface for X264 or X265 or any other encoder/codec that it has access to. Cheers, Dave.
@@dimmacommunication As long you are good with it so why not 😅😅 I'm thinking to change to 2070 S just for the codec (: Mostly for the filesize and speed to compressing :)
I already have an 5500 XT, and I'm about to get an Ryzen 3950X. I'm going to do x265 encoding so should I let the 3950X do the encoding, or the 5500 XT, or do I need an Quadro P2000 to get the fastest times? Sorry as this stuff still confuses me, Gary. ps. I don't game, so that's why I don't have a higher end video card.
Hi Gary. If it's X265 encoding you are doing then just get the most powerful CPU you can. Handbrake using X265 will multi-thread, so AMD CPUs will generally be better/faster and cheaper than similar priced Intel CPUs. For specific GPU assisted encoding, such as NVENC or Quick Sync like I've used in this video, they will encode a lot faster than any CPU using X265 but X265 encodes, especially at lower bit rates, will look better than any GPU assisted encoding if you use the longer encode options for X265. This is also the case for X264 as well. Although I don't use AMD's variation of GPU assisted encoding in Handbrake, the general consensus is that AMD encodes, like for like, are not as good as Nvidia's NVENC or Intel's Quick Sync. I hope that helps. Cheers, Dave.
Hi George. Using X265 which is the software encoder, takes a lot longer even on a powerful multi core CPU. Using either X265 or even X264 for h.264 will give you a lot more parameters and encoder complexity but even using their parameters that give their fastest encodings they are much slower than any of the hardware assisted encoders. Cheers, Dave.
The problem with software encoding is that it’s going to change from person to person because of their CPU. One person’s figures without mentioning their computer setup, CPU etc. is meaningless as the CPU is the point of reference, without mentioning the CPU there’s no point of reference. The easiest thing to do is try it for yourself, just download Handbrake it’s free.
I have an 8700K and an Nvidia 1080GTX. The NVEnC option is about 6 times faster, even if using high quality mode. Thanks. Also, some of my older apps can't use GoPro H.265 files. If I use Handbrake to make it in to H.265 again some of my older apps can use the H.265 from my GoPro.
Hi Richard. I started using QS with the i7 4790K and have noticed as Intel introduced new CPUs that their QS encoder has gotten quicker. This isn’t always the case as Intel sometimes skip a generation before any noticeable changes. The same is true will Nvidia, from Pascal to Turing for example the NVENC encoders changed. This is probably why your results may be different to mine, as in the speed differences between QS and NVENC. In any event and as you’ve proven yourself, NVENC is quicker than QS when set to their slower best quality settings. You’re transcoding routine is very interesting, I’ve also noticed my GoPro H.265 files are problematic on certain playback platforms. Cheers, Dave.
Can someone help me ? I am trynig to compress MOV file to H265 using handbreak, but when process end file is in mp4 and it only plays audio, not video showing. why ???
I been using NVEC h.265 on my 1050 ti for about a year (running a 2700x cpu) and on an average a 1080p movie takes about 12 mins. I am trying to find out if the NVEC encoder has improved enough on Turing GPU aka 1660 ti to justify the upgrade. Would you have insight to this question? PS. Good video btw
Hi Brian. Yes the encoding has improved. I no longer have anything earlier than a Turing GPU so cant do a direct comparison, although I’m sure there’ll be some comparison videos on TH-cam. If you use OBS, there’s now an option for V2 for the NVENC encoder as well. Just so you know, there is no difference in encode speed between the 2080 I used in this video and a GTX 1660, they are both Turing and use the exact same NVENC encoder. Cheers, Dave.
Thanks so much for this video, was looking at the benefits of upgrading my GTX 760 card to a GTX 1660 Super for video encoding.. and it's been a learning process! The GTX 760 does not support h.265 encoding in NVENC, and I have learnt that lower bitrates in NVENC (on older cards like mine anyway), are not so good. I used your video to put the theory to the test myself on a 720p60 clip in Handbrake, competing h.264 software encoder with the GTX 760 NVENC h.264 encoder - like your video, set to highest quality/slowest encode for both, and a low (2Mbps) average bitrate. The difference was like night and day.. yes the NVENC did it in 38 secs, and h.264 in 3 mins 23 secs - massive difference, but also was the quality - h.264 software encode was far better quality for the same file size. I'm going to upgrade my video card still as I know the 1660 has a newer NVENC engine with better quality and h.265 support, and I may even repeat the test to see if quality has improved, but your video really helped, so my advice to others would be use NVENC on older video cards only if you're using a higher bitrate, otherwise if you can spare the time, use h.264 encoder in CPU.. it could be worth the wait for files at lower bitrates.
Hi Daz. Thanks for the comment. As for X264, I do use this for low bitrate stuff. In fact I've been using for over 10 years now and have actually used it for some blue ray streams. If you set X264 or X265 to their highest settings, which does take an age to encode, you will never get anything better for pure picture quality at the lower bitrates. As this particular video was specifically for speed, I didn't want to use X264 or X265 in case people thought anything bad of them because it would have taken way way longer even compared to QuickSync. I may do a video soon showing how good X264 and X265 are for encoding low bitrate video. For that video I will also do downloadable examples. Overall though, for anyone using moderate to high bitrates, there's no real reason to use X264/X265 as the differences in picture quality between all the encoders becomes almost indistinguishable and at that point and it's probably better to get the job done faster to save time. Cheers, Dave.
@@DavidHarry Thanks Dave, I now have a GTX 1660 Super and have re-run my encoding test. For the benefit of your viewers I can confirm that although the new NVENC is still not as good as software h264, the encoding speed was significantly faster (more than halved the encoding time), so for med-high bitrates, definitely go for hardware encoding if an option. Regards, Daz
Nice one Daz, thanks for the update and extra input, I’m sure it will be useful for others and a great choice for your GPU. I’ve got the standard 1660 and it’s perfect for NVENC encoding, the Super in my opinion is the best value GPU out there for the balance of gaming and doing some production stuff. If you’re into OBS your new GPU will also give a second, newer option for NVENC h.264 encoding. I use this all the time for recording game play, not streaming, and it’s immense. Cheers, Dave.
I'm looking to upgrade my video card from a GTX 720 to 1660 for x.265 NVENC encoding because I'm getting tired of watching my i7 CPU take 2 to 7 hours to encode a single movie while running at 99% and almost overheating the (CPU 72c / 161 f CPU temp!)
I meant what was your final HandBrake file going to be used for, as a TH-cam upload or just as a final viewing file etc. Plus, if you’ve started off with something that’s sourced at a low bit rate such as 6mb/s then it’s debatable that you’d need much beyond that as your final output from Handbrake, as you won’t really feel the benefit of a higher bit rate as you would if the source files were of a high bit rate. If you checkout some of my other videos and watch them in 4K, you’ll see that they maintain quite a bit of quality because I use high bit rates all the way from capture, editing, intermediate, final TH-cam upload and then when TH-cam does the last encode to its lower bit rates. If you go to www.TheGameThing.com this will take you to a channel I have that I’ll be doing some gaming videos on, at the moment it has a bunch of test encodes. Some of these are at 200mb/s and uncompressed for their uploads for the 4K/60 stuff. The higher the bit rate, doesn’t always translate to much better final quality at the TH-cam end. With video encoding, especially for game play or graphics based video, it’s massively diminishing returns with high bit rates. Cheers, Dave.
The title is not misleading as it clearly says that NVENC and QS are being used, it says nothing about X265 because I’m not testing for any software solution, only hardware assisted acceleration.
XMedia Recode has 4:4:4 chroma subsampling (full RGB) and that makes A LOT of difference in image definition and color accuracy (if your original file is 4:4:4). Handbrake doesn't have that option.
@@TheGameThing I does make a lot of difference. I've converted a 2.K video with the same bitrate from MP4 444 to MP4 420 and red lines on the video became blurried.
No it doesn’t. You can’t increase colour sampling beyond what the recording was. You may have seen something that helped your particular file but it definitely was not an increase in colour sampling. Besides. This video is showing NVENC and QS, this has nothing to do with Handbrake’s ability to process as handbrake is only a host GUI controller for the NVENC and QS encoders.
@@TheGameThing My original file is 4:4:4. So yes, it does make a difference when I try to downsample it. The problem with Handbrake for me is that it doesn't have a 4:4:4 option, while XMedia Recode has.
Your 444 file won’t make any difference in either NVENC or QT, neither will processing that chroma sampling space with regard the output. So, once again you are wrong about Handbrake, in this video as it does nothing with regard sub sampling. Everything in this video with regard video processing is handled natively by either NVENC or QT, not Handbrake. You really need to understand what you think you are criticising before commenting and getting it wrong.
I was wondering if the 3060 could encode h.265 and AV1 (like if I was to convert some videos from one format to either of them. It would not make or break a sale by any means. I just wondered if it or any of the 3000 series does it. I am just trying to find a price that won't make me have a heart attack and the 3060s are not too horribly overpriced (though they should be $300 cards).
Hi David, I am using a 3rd generation i7 3770 Non K CPU with 12gigs Ram and recently installed Geforce GTX 1660 Super and I am able to use H.265 NVENC in Handbrake Application. But as per spec sheet on Nvidia gtx 1660 super encoder can encode HEVC 8 bit and 10 Bit on HW acceleration including B frames. Could you please advise how can encode H.265 NVENC with options 8 and 10 bit along with B Frame between 3 to 7
can we have H.264 and using older gen nvenc , because in RTX series they did buffed it up a good amount , so on gtx 1080 ti the encoder is slower. so if possible maybe a 1080 ti or 1080 vs qsv h.265+ 2.64
That was fast for 4K. I am using a cheap Win11 laptop with 4GB RAM, often it takes about 30 mins (sometimes upto an hour and half) to encode a 20 min AVI raw file capture at 720x576 from a captured analogue tape using the H.264 encoder, setting at a bitrate of 8000kbps, 25fps and at the fast speed setting. My processor must very slow lol. I'm guessing I need something like an I7 processor with at least 16GB RAM.
Hey David thanks for such an informational video. I dont havemuch knowledge about video encoding so pardon my silly question. My video is a 1080p 30 fps OBS recorded mkv file Size 650 MB, my PC specs intel i7 7700HQ and nvidia 1050ti. i followed your video and for NVENC i used the following settings : web optimized "constant quality" at 24 and "optimize video" at slow encoder preset and when i run it it did the whole encoding work and finished in 1 minute(insane!) and final size was 80 MB But when using the intel 10bit QSV settings with quality at 24 and "encoder preset" at Quality i am getting the final output in 8 minutes(which is 8times of NVENC) but the final file size is 40 MB(half of NVENC final file).so is there any way i can reach a middle ground here with a little bit of more time consumed i want the file size to be reduced too like the intel qsv. what do you suggest i should do i plan to use the file for my consumption and uploading on google drive ?
Hi. My settings don't use CQ I use a fixed bitrate, CQ can be different depending on the codec being used. Try using a fixed bitrate using NVENC and maybe try a fixed bitrate VBR with other codec options. Somewhere in there you'll find the happy medium between time and size. The thing with this type of stuff is that it's not really worth one person advising another person on things such as bit rate etc. For instance, I'm prepared to wait for long encodes so I can get maximum quality at a given bit rate, most people don't want to do that. Just do some short 1 minute encodes with your average type of content to see what bitrates suit you. Cheers, Dave.
@@DavidHarry Thanks, Dave. There are so many questions I have with your explanation underneath the video that I'm going to have to go away and try to get them in some form of sensible order before posting them.
Hi Ray. When you've got the questions we'll chat about it on the Osmo forum, it may help others there. There'll be another video shortly, I'm just waiting for TH-cam ti render the UHD stream. Cheers, Dave.
@@DavidHarry Ok Dave. Will do it there. I've not long finished an 11-hour working day so turning in now. I'm out again at nine tomorrow morning. Will get onto it as soon as my brain has time to settle down.
Dude when you set the bitrate too high like 100000 you kill the purpose of experiment. The encoder time is mostly employed by compression algorithm. When you set it too high, encoder just skips the serious part of the compression job and dumps the data straight to the output file. For a 4K video, 50000 Kbit/s means high quality even with h264. You are using h265 which needs less bitrate for the same Q.
you can not encode with nvenc and quick sync with only one monitor output, you should have 2 separated video signals, one from nvidia, and the second one from intel cpu itself......, in my case, quick sync is 8 times faster than nvenc 3060, because i have 2 monitors, one hdmi pluggin in to my IGPU, and one to my rtx
This video didn't say anything... I would want to see filesizes of outputs. Also pure CPU would be necessary for the benchmark. Basically you would get Nvenc faster, but higher filesize, while cpu is slowest and lowest filesize. QSV is optimal bettween speed and filesize, which is in between. 4k with 100 MBit is an overkill. 24MBit is what I would use on 4k HEVC. Maybe you have 8k camera? And also when you use NVENC it removes BT2020 colours, and converts to BT709. YOU HAVE TO USE PURE CPU to preserve your colour quality, otherwise you are just wasting time... Maybe newest gpu can preserve BT2020, but it needs lots of testing to find out...
Why is the color space is being altered using NVENC and not on a CPU? Nvidia GPU's don't have any clue about HDR (rec/bt2020) or SDR (709), they simply use NVENC10bit 4:2:0. ..
GPU encoding is usefull only for reltime encoding when space is not a problem. Because I tested CPU x265 slow encoding and nvenc quality encoding : the result is that nvenc need more than 2 times the space x265 need. If you want quality at not very very high bitrate, GPU is not the solution. Speed or quality you have to choose.
GPU is better than X265 when file size is not a factor as you can encode way way faster and high bitrates there is no visual difference between GPU and X265. Don’t forget, this video had absolutely nothing to do with CPU encoding and therefore nothing to do with X265, this video was clearly all about the speed differences between two hardware technologies, NVENC and QSV.
@@DavidHarry OK but people should remember that compression means saving space on disks. A compression that do not compress (as deeply than x265) is not a very good compression. So hardware compression is only for realtime compression (that will need a real CPU compression after to divide by 2 the file size). This need to be said to avoid people think there is a solution where there is not. I bought a nvidia card to compress my vidéos (films). I saw I got a 2 times bigger file size than with CPU encoding. I stopped using GPU. If people told more on social networks that GPU encoding means a 2 times bigger file than CPU encoding to get the same quality, I would not have mistaken. What a pity GPU encoding do not enable us to get the level of quality we want (I would prefer a 5 times slower compression with x265 like result). perhaps because it is not doable with GPU that is not as smart as CPU.
Video compression is not just for saving space on disk and making files as small as you can. If that were the case and going by smallest must be better, as you are saying, then X.265 wouldn’t be that good either because certain VP9 and VC1 encoders beat H.265 files produced by X.265 for file size. Plus there are other proprietary codecs that beat X.265/H.265 for file size. Like I’ve already said, this video and it’s title are clearly talking about hardware encoders, not software encoders. Keep an eye on my channel as I will do a video soon comparing X.265 and NVENC for the smallest file sizes. I’m sure you will like this comparison as it will clearly show what you are saying, X.265/H.265 encodes very clearly win in picture quality at small sizes VS NVENC but that comes at a massive cost in time.
@@DavidHarry in fact it depends on what people call small size. For me small size means below 10 000 kb/s in 1080 for h265 (8 to 10 GB for a 90 mn film). But even at 10 000 kbs, x265 slow beats hardware encoders by far (I have tested, no comparison possible). I think I would need 100 000 kbs to get an equal quality (I have not tested because it is not interesting for me). Can you tell what you call small size in kbs ?
If you are not prepared to test for yourself, then how can you possibly give any numbers/figures. Your numbers are nowhere near accurate. You’re the one who mentioned the word small but your version isn’t that small.
Qsv is faster with Intel processors designed with iris plus graphics, the one used in this test is a gt2 or HD graphics processor which wasn’t designed for encoding or gaming. I have a several year old intel NUC “skull canyon” that would be faster since it has 72 execution units. Here’s a list of your looking to support 10 bit encoding at the fastest possible speeds. en.m.wikipedia.org/wiki/Intel_Quick_Sync_Video also this one en.m.wikipedia.org/wiki/List_of_Intel_graphics_processing_units
@@DavidHarry you were right. I ran a test with my i7-6770HQ and it was 15fps. So is the quick sync portion of the chip independent of the rest of the GPU? It appears that Intel hasn't updated this feature except to support 10bit encode.
Hi. Yes, that’s right, the QS encoder is a different part of the architecture to the rest of the GPU. You mentioned the execution units earlier and yes, they do make a big difference with pure GPU tasks between different Intel iGPU versions but many tend to have the same QS chip. I use Intel based PCs for running versions of Android on PC, basically AndroidX86 variations. I use this for Android game play and different versions of Intel CPUs with their iGPUs will play games better the more powerful the CPU/iGPU but will still only be about the same for encoding when under Windows with anything that takes advantage of QS. Intel’s QS encoder has changed over time but not much and not as often as Nvidia and their NVENC encoder. Nvidia put more effort into NVENC than Intel do with QS. The latest version of NVENC is actually the same on an RTX 2080 ti as it is on the GTX 1660. Which is great news as the 1660 is way cheaper and just as fast as a 2020 for encoding, obviously the CUDA core count and GPU power of the 2020 are way ahead of the 1660 and will leave it in the dust for game play etc. but at least Nvidia have put a great encoder even on their cheaper cards. In fact, even an old GT710 can do H.264 via NVENC, I think that was Maxwell architecture and you can pick one of those up for less than £30 new and it will be faster than Intel QS doing H.264 HD, I can’t remember if the 710 does UHD/4K. Cheers, Dave.
Thanks for the info. Now I've changed my video library compression from H264 with half the video time length for compression (for a 2h movie, it lasted ~1hour) to H265 with 6 min transocding :) Very nice!
@@DavidHarry Care to elaborate? NVENC is "a feature in its graphics cards that performs video encoding, offloading this compute-intensive task from the CPU". That means the GPU does the encoding, So I think it has absolutely everything to do with a GPU. Source: en.wikipedia.org/wiki/Nvidia_NVENC
NVENC is separate tech to the GPU, just as QS is to Intel or AMR to AMD. That’s why it has nothing to do with the GPU, the GPU does not accelerate the encoding. Further proof is when you put a RTX 2080 up against a GTX 1660, they both encode at the same speed yet the GPU in the 2080 is way more powerful. Again proving it’s not a GPU related task but a task assigned to a separate DSP processor that’s conveniently on the same GPU board that is designed to do only one job only, encode video.
Not obvious to me. One would think the processing power of a CPU is much more powerful than that of a GPU. A CPU is basically built solely for calculations.
Hi Tide. Prem was my first NLE about 25 years ago, I've always had a soft spot for it, first love :) I haven't used it in a very long time and didn't know that it doesn't support NVENC, which is a real shame as it'd really help. As for the PC, I'm just finishing a bunch of videos about its build. I'll post those on the DJI forum as they may be useful for Pocket and Action owners. Here's the intro to the main video in that set, I got my 8 year old nephew to give me a hand for the intro :) th-cam.com/video/6-dqLmuqwZw/w-d-xo.html Cheers, Dave.
Hi Dave, Premiere supports Quick Sync but not yet for NVENC. I am interested to check out the PC build. 😊 Pocket or Action's 100mbps file is not easy for CPU and memory to handle on timeline playback. Cheers! 👍
Quicksync is terrible, files are always huge, the quality is always horrendous, artifacting is an issue. Nvenc actually works... But I'd rather use the CPU as speed isn't my number one priority.
Make sure that whatever is playing the file is actually compatible with the file and its video and audio codec. Can you play the file back on the computer that you encoded it on? If so, this means that there is no problem with the file and the problem is with your player or display. 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.
------------------------------------------------------------------------------
Please consider supporting my TH-cam channel by liking, subscribing and clicking the bell icon for notification of future videos. It really does make a big difference and also please share my video links. Or use my Amazon affiliate links when purchasing from Amazon, I receive a commission that helps my channel.
www.amazon.com/shop/davidharry
www.amazon.co.uk/shop/davidharry
Thank you very much for watching this video, take care and goodbye now.
Cheers,
Dave.
David! Why do you use Handbrake? It is very bbackward software with few options. Moreover, it does'nt use the in-card compression technology, where the video data is not copied to the system memory during compression and back to the card etc... You can achieve better performance and quality if you use more sofisticated software like the Hybrid . You can find Hybrid at Selur.de
I'm curious about the file size, NVENC 265 has always been really large vs standard 265 for me.
@@Celebrate81 ok i just did try your suggestion , that hybrid don't even support h.265 in qsv or nvenc so i don't see how it can be considered superior to handbrake while its missing a key feature that is very important
what is in those XXX Masters 2019 folder?
pls contact me personally, i'm ready to pay you for some high quality erotica!
Would have been SUPER helpful to see file sizes of the outputs.... Surprised that needs mentioning. Second, would have been SUPER helpful to see if there is any noticeable difference in quality of the video playback between originals and the 2 new versions.
Would have been SUPER helpful if you’d have understood the whole point of a SPEED test, which has absolutely NOTHING to do with SIZE or QUALITY.
@@DavidHarry Sorry to say, but speed means nothing if quality is bad and file size is horrendously huge.
I do appreciate your video.
In regards to my own NVENC testing. If everything is the same as your CPU HEVC except the encoder that was selected than you're looking at 2-3 times the file size of the CPU encoded file to have roughly similar quality.
@@DavidHarry It's called a sanity check. It might not be the point of the test, but it's not wrong to just do a quick sanity check.
@@GoatZilla As I’ve already said, the video was strictly dealing with a “speed” test nothing else. There are a whole number of other things such as very specific encode parameters used etc. That could also have been mentioned, but where do you stop and draw the line between what the video is specifically about and other extra information. Trying to cover all bases for what else may be asked from any such test is just going to result in a much longer video that de-focus from the main point. Plus the big issue with the request for file size, is that this will only have a bearing on this exact encode, it will have nothing to do with any other encode. Cheers, Dave.
Can u plz mention the changes in file size
Yeah good video bla bla bla. I'm curious about that "XXX 2019 Masters" folder, what's up with that?
Uhmm... work documents I guess
Writing an academic paper about xxx
Hi, it would have been nice to see a comparison between the two files in terms of image quality.
Hi Al. The idea was to keep the video short plus it’s difficult to do certain comparisons due to the extra encoding that TH-cam applies. Keep an eye on my channel as I will be doing a video comparison where I will link to a couple of download files so people can see the differences properly. Cheers, Dave.
@@DavidHarry Thanks Dave, I'll be looking forward to it. :)
Hi Péter. What you’ve said is completely wrong. Handbrake is only a GUI that controls various codecs and in this video it’s only used to control the hardware, handbrake itself is not doing the encoding. Even in software mode what you’ve said is wrong as well, as the encoding is done by X264/X265 etc. again not by handbrake itself. Cheers, Dave.
nice video harry. could you please share their file sizes as well please
I saw is not the same quality choosen for test . You chosen encoder present quality for QSV full setting but for NVENC slow...
Hi. The settings for both encoders are the ones that produce the best quality for either encoder. Cheers, Dave.
@@DavidHarryI want to encoder my gopro video for H265 + which configuration is batter for me Intel core i7 9700k with 630hd or amd ryzen 7 2700 with nvidia gtx 1660 thanks
Hi. Between all three encoding methods, Nvidia/NVENC, Intel/QSV and AMD/AMF, NVENC is the best. At higher bit rates, NVENC and QSV will both look very good, AMF can sometimes have problems and doesn’t look as good even at high bit rates. At lower bitrates you will notice that NVENC will produce a better looking encode. At any bitrate or picture complexity, NVENC is also the fastest. The GTX 1660 will produce the exact same picture quality as a RTX 2080 ti and will be just as fast, they both use the same encoding engine. I hope this helps. Cheers, Dave.
Placebo is not a better quality, it's more like an experimental feature, that actually does the opposite sometimes, the size of file increases and quality might be the same as slow, and FPS is very very low....
Do you think is amd ryzen 7 3700x + rtx 2080 ti batter than i7 9700k + rtx 2080 TI for encoding H 265..thanks
Hi David, you say the quality difference between x.265 and H.265 NVENC is small at high bit rates. What rate you consider a high bit rate? I have been encoding UHD full length movies in x.265 at 9000 kb/s and it takes about 2 days to encode with a i7-9900k, or 1 day with dual Xeon 6146's, but I recently tried H.265 NVENC on a UHD movie and it only took 2 hours. I thought that 9,000 kb/s was high, but you used 100,000 kb/s. I never dreamed anyone would actually consider using a value that high. At what bitrate does the quality difference become minimal, because man, I would really like to start using NVENC on everything due to the speed increase.
Hi Thomas.
Great question, thanks for asking. The bit rate will all depend on the source material. If for instance you started off with uncompressed video, such as a film/studio master, then you can go to relatively low bit rates as the master would have contained very high picture quality such as colour, resolution, bit depth etc. Such masters will be using an intra-frame codec, basically a codec that uses unique and individually encoded stills for each picture, also called I frames. Then there's motion properties to consider, fast movement within the frame or fast movement of the camera. But because the master will have been of such high quality, it can handle being encoded to low bit rates using a destructive codec such as H.264 or H.265, which will throw away a lot of the information from the master but can still look awesome.
If your source material is something that's already been heavily compressed, for instance camera footage using H.264 or H265 or maybe ripped movies. This footage may well look great but will have been encoded very heavily using the inter-frame encoding method. Basically only a few frames in every second are unique, although still heavily compressed, these are I frames and the other frames, predictive and bi-directional, P&B frames, are frames made up one way or another with information taken from that point in time from the original source or a lot of information from adjacent frames. This method of redundant encoding can look awesome but it is none the less heavily compressed, so when encoding from a source like this you are compounding encoding artefacts from one heavily compressed/destructive encode to another. In this instance a higher bit rate is necessary to maintain quality due to the compounding encoding/codec effects of using a heavily compressed inter-frame codec.
I know what I've just explained is an over simplified version of what goes on and there other factors to consider but that simple explanation is good overview.
While 100,000Kb/s may sound very high, it is in fact very small when compared to an uncompressed master of the same material.
I used 100,000Kb/s in this example as it is what I use for own TH-cam uploads. I use this bit rate as my camera footage is either H.264 or H.265 and is already heavily compressed before I edit and re-encode it and I need to maintain as much of that quality when I export my final edit at UHD/4K 25FPS, because after that, TH-cam then re-encodes it further and will effect the quality even further. If you have a skim through my TH-cam videos and watch the UHD/4K versions, most of the footage holds up quite well and still looks sharp etc.
I'm gonna start a game type channel in a couple of months showing various tech stuff to do with gaming and various things such as Android and console stuff etc. I've already got a few examples of some walk throughs and game play there. Take a look at this stuff in UHD/4K. As it's 60 FPS, some of the stuff is uploaded at 200Mb/s (200,000Kb/s)
th-cam.com/channels/4XX0WWrHCObF36PWsmCj7Q.htmlvideos
Getting back to your scenario with NVENC & X265. No matter what you encode you will always destroy picture information, this can be lessened with high bit rates, or longer more involved encodes such as using certain options with X265. There is always a practical trade off with encoding, speed vs quality vs size. There's no doubt that X265 and X264 are the best encoding methods for both the H.265 and H.264 codecs with regard picture quality and size but it does come at the cost of speed. Out of all the GPU assisted methods of encoding, my tests have shown NVENC to be the best and also the fastest.
For your personal use I think using X265 and waiting a day or longer is probably proper boring and impractical. If I were you I'd just use NVENC and pick the lowest bit rate or Q rate that you are happy with for quality and final file size and encode at a fraction of the time. Like I said, encoding involves many trade offs but it's always best to use what's best for you and your encoding setup. One thing I would say though and bear in mind I've worked in audio production for over 30 years and video production for over 25 years and used to author VCD using MPEG1 and I'm always looking for the best possible quality. I wouldn't recommend chasing the CPU route and buying more expensive multi core CPUs so you could speed up X265, I'd simply find the quality you'd be happiest with with NVENC and benefit from the speed and lower cost. Don't forget a GTX 1660 will encode just as fast as a RTX 2020 as they both use the same NVENC encoder but the GTX 1660 is a fraction of the price of a RTX 2020 and much cheaper than high core count multi-core CPU. NVENC has gotten better and better over time and I'd guess that will carry on and maybe one day X265 may be able to be accelerated with the same great quality but much faster using CUDA or NVENC.
Anyway. I hope this reply has helped, I'll have to get off now as my encode for today's TH-cam upload has just finished on HandBrake using NVENC at 100,000Kb/s for my UHD/4K TH-cam master file. Now the boring part, uploading a 9GB file to TH-cam on a internet connection over 4G on my phone :)
Cheers,
Dave.
This video would have been more relevant if the resultant file sizes were compared, and a brief review on whether the final video was of acceptable quality or not... just my 2 cents.
The point that is missing here is how big the output files are, most of the times with qsv the encoded file ends up being bigger than the original one!
No, the point being missed here by you and many others is that this is a speed test, it says so in the title. The title doesn’t say quality or size, it says speed test and if you don’t know why QSV is producing larger files than the source then you really need to understand that before questioning other things that you obviously don’t understand.
@@DavidHarry no man, you clearly said you wanted to preserve quality, and file size is clearly as important, you just missed it and it would have taken nothing.. great video btw
Can't enableing Intel NVENC in settings
Handbrake version 1.3.3
You need a compatible NVIDIA graphics card.
What about the video quality of the two output files? You didn't show that. I'd accept longer time for better quality video.
In general same quality but withj a file 2 tiems bigger for nvenc. So nvenc gives in reality 2 times less quality (at same bitrate). That is why I do not use it.
What is the file size after handbrake export
9 minutes 08 seconds and 100000kbps means around 6689 megabytes.
Good to see that someone knows how to calculate the size. I really don’t understand why people take the time asking certain questions when it’d be much easier just getting a calculator or if they don’t know the difference between bits and bytes, just Google it. 100000x548÷1024÷8 Cheers, Dave
@@DavidHarry LOL.. Good one. It's much easier to get a calculator and compute the sizes then to just have them reported. Like the dry humor. LOL.
Are the 2 output files visually identical?
Hi. At such high bitrates there won’t be much visual difference between any two different encoders. It’s at low bitrates where better encoders will be visually and technically noticeable better. I’ll do a video soon using QuickSync, NVENC and X265 at low bitrates for quality testing, this test will have downloadable files. Cheers, Dave.
@@DavidHarry Would this also be the case if, for example, you had used the "balanced" preset for Quicksync?
@@DavidHarryfor this type of encoding only cpu can handle that task?? Without dedicated GPU??
Hi David. I appreciate you running the comparison, but I have some questions. What was the final file size for each? What is your opinion of the final quality for each? How long does it take to do the same encode without either HW acceleration using the i9-9900? What is that file size? How does that quality compare? Thank you!
I am weighing a i9-9900 vs R9 3900x build. I do a lot of long 4k High school sports video encodes. I am always trying to minimize encode time and file size without giving up too much quality. I have experimented with NVENC, but do not get the same quality vs file size on my GTX970 as in software on an aging i7-2600K. The i7-2600K supposedly has the first generation of QuickSync that supports h.264, but not H.265. However, Handbrake doesn't appear to support QuickSync for i7-2600K so haven't tried it.
@@davidbaldwin3407 would be difficult to use AMD's version of quicksync, not sure if it's supported any more. 3900x might faster in straight CPU encode though thanks to additional cores
David Baldwin the filesize was the same as both used the same bitrate
Can you redo this video with Intel ARC A770 vs RTX 2080.
If I had those cards I would but I don't have them. Although it would an interesting test. Cheers, Dave.
Does slow preset offer better quality than placebo?
would be great if you run another test like this but with UHD 730/750/770 vs 7th Gen Nvenc
I am curious if you use any 10bit HDR videos trying to find a good process for 10 bit hdr video
Hi Donovan. Unfortunately no, not yet. All my camera stuff is only 8bit rec709 and the same with any of the game capture stuff. I may be changing cameras at the end of the year, so will be doing HDR stuff then and I may start doing some HDR game stuff as well, as I can edit and view HDR. Cheers, Dave.
video file size after encoding??
hmm your orig file was 1536 kbps so why would you want to encode at 100,000 kbps? just curious as i have no idea how all this works? also you showed info on the file before encoding but not after ie file sizes and bitrate it actually is now? I would assume the file size was bigger then when you started if it works how i think it does? I have no idea on this stuff and its why I am asking.
Hi James. As per the title, this was a speed test. As such, attributes such as file size and quality didn’t matter as neither would make any difference to the outcome of this particular test. Changing parameters such as encode quality for the output during the test would make a difference to output quality when combined with bitrate and would also change the speed of the encoding. However, as certain parameters were set as a constant, it was the best way to make a comparative measurement for the speed. Cheers, Dave.
@@DavidHarry but wouldn't a more normal bitrate also make it go faster to? ie if your encoding for speed you still wouldn't want to encode at higher bitrate then what it already is as that might slow it down to wouldn't it? Ie couldn't it take longer for one of the ones you tested go faster at bitrate you would actually do it at etc? Like i said i have no idea just asking really as trying to learn this stuff to convert some stuff myself. Thanks.
Hi James. No, not with this setup. You’ll find most encoders, especially hardware encoders which is what’s being used in this test, won’t change the speed when changing the output bitrate. In fact, I don’t think I’ve come across any software encoders that would change the speed either. The only reason why the bit rate was what it was, is because this is one of my usual bitrates for my own TH-cam uploads. You have to remember, this video and the way that I would create a TH-cam, aren’t being done for the best quality at the lowest bitrate. When making an encode to be the best at the smallest sizes/bitrates, you’d use different encode parameters to make that happen but your encode would take a lot longer. However, if you don’t need small files that take ages to do, then large fast files are more appropriate. In certain instances, it would take me longer to make a small/slow file and upload to TH-cam, compared to a fast large file and upload that to TH-cam. This is because my upload speed will be faster than the time taken to make a slow/small encode, so fast large file makes it quicker to get the whole TH-cam upload done. Don’t forget, when you make an exhaustive slow encode at a low bitrate, it won’t look any better than a fast encode at a high bitrate. If you are interested in encoding, I’ve done many types of encoder tests on my channel. I will also be doing some more soon and some specifically for slow low bitrate. With the quality slow tests I will also be including some download files, because it’s pointless showing a slow encode on TH-cam as TH-cam only re-encodes the file and makes it worse, so you still never see what the original file was like, which is why I’ll be including downloads. In fact, you’ll find some of my previous tests have downloads as well. What type of stuff is it that you are encoding? Cheers, Dave.
Forget the speed test, which produces better QUALITY?
On both of these you can choose your quality in the lower left. Instead of using fast, medium, or slow, choose high quality. Also, choose a higher bitrate.
@@RichardsWorld No I know that 😊 what I meant is does NVEnc at best quality setting produce better video than Quick Sync at highest quality setting ?
Hi. If using high bitrates you’d be hard pushed to see any differences between the two. If using low bitrates and setting both encoders to their best quality encode settings you will see that NVENC produces a better looking picture. If you want the absolute best possible quality, using X265, which is the software encoder, will produce the best quality at low bitrates. Although, to do this you have to use its slow settings and the encodes are very slow even on a multi core CPU. I may actually do that test as it is interesting and give downloadable examples. Cheers, Dave.
for quality you should choose rendering on CPU. GPU-s are great at optimizing speed, but not video quality.
@@TabalugaDragon That was true some time ago. However if you have tried the latest Intel Quick Sync on Coffee Lake or Turing/RTX 2080's NVENC, you will find it handily beating x264 and x265 in quality as well as speed. Which is what I was asking for confirmation but then I got these latest GPUs and confirmed it myself. See here also: unrealaussies.com/tech/nvenc-x264-quicksync-qsv-vp9-av1/
WHAT WERE THE SIZE OF THE OUTPUT FILES WHEN DONE?
How much is the CPU used while encoding with NVENC? I'm contemplating getting a new turing card but my CPU is weak so I'm not sure if I'll need a CPU upgrade or not.
Hi Bryan. The CPU doesn’t matter, the GPU does all the encoding. If it’s mostly encoding you’ll need the GPU for, the GTX 1660 is a great card, it will encode just as fast as the RTX 2080 ti. Cheers, Dave.
So handbrake is the best video encoder ?
Hi Andrea. In this instance Handbrake isn't an encoder, it's just controlling the encoders for NVENC and QuickSync. Even in software encoding Handbrake still isn't the encoder, it would then be just an interface for X264 or X265 or any other encoder/codec that it has access to. Cheers, Dave.
@@DavidHarry Thank's , but quickly speaking , how can I have good encoders ? I have a AMD RX 580, how can I download the encoders ?
@@dimmacommunication Hi, you need to have a Nvidia GTX 980 Series or higher graphic card to be able to record, compress and and use H. 265 :)
@@Mr.Handymaan Actually I am encoding with my AMD 580 pretty good now , I found nice settings :)
@@dimmacommunication As long you are good with it so why not 😅😅 I'm thinking to change to 2070 S just for the codec (: Mostly for the filesize and speed to compressing :)
I already have an 5500 XT, and I'm about to get an Ryzen 3950X. I'm going to do x265 encoding so should I let the 3950X do the encoding, or the 5500 XT, or do I need an Quadro P2000 to get the fastest times?
Sorry as this stuff still confuses me, Gary.
ps. I don't game, so that's why I don't have a higher end video card.
Hi Gary. If it's X265 encoding you are doing then just get the most powerful CPU you can. Handbrake using X265 will multi-thread, so AMD CPUs will generally be better/faster and cheaper than similar priced Intel CPUs. For specific GPU assisted encoding, such as NVENC or Quick Sync like I've used in this video, they will encode a lot faster than any CPU using X265 but X265 encodes, especially at lower bit rates, will look better than any GPU assisted encoding if you use the longer encode options for X265. This is also the case for X264 as well. Although I don't use AMD's variation of GPU assisted encoding in Handbrake, the general consensus is that AMD encodes, like for like, are not as good as Nvidia's NVENC or Intel's Quick Sync. I hope that helps. Cheers, Dave.
@@DavidHarry Ok thanks for all the info.
@@DavidHarry The RX 5500 has the new VCN engine, have you tried with Navi architecture cards?
I have an AMD card and seems to not work with x265 in Handbrake ... :(
What is the size of the file after this process ???
I know it was not the point of the video, but I would be curious to know how long that file would have taken using software only.
Hi George. Using X265 which is the software encoder, takes a lot longer even on a powerful multi core CPU. Using either X265 or even X264 for h.264 will give you a lot more parameters and encoder complexity but even using their parameters that give their fastest encodings they are much slower than any of the hardware assisted encoders. Cheers, Dave.
@@DavidHarry I hate to be a pain, but how would you define "a lot" as in "a lot longer" or much as in "much slower"?
@@georgewright1093 In slow(quality) mode using NVEnc I'm still got 150-160 FPS while in software mode go so slow 10-20 FPS.
@@MrBuash Thank you, that helps make it more concrete for me.
The problem with software encoding is that it’s going to change from person to person because of their CPU. One person’s figures without mentioning their computer setup, CPU etc. is meaningless as the CPU is the point of reference, without mentioning the CPU there’s no point of reference. The easiest thing to do is try it for yourself, just download Handbrake it’s free.
What are the sizes of the encodes?
Speed wasn't the priority. Can you share results at 18-20 CRF? NVENC v Quick Sync QSV v HEVC (software) quality comparassion at 1080p or 4K.
@Mike P I think same things with you. But I wonder hevc_qsv. It could be better than x264 (software) or similiar quality but faster.
How can i play 4k ultra hd format on my lcd through USB? I added 4k preset and encoded in handbrake but still the video didn't play on tv
This was good to see as I shoot with HEVC and H.264. I have been wondering if there are better ways for me to encode my videos. Thank you.
Mike P I can see this as well. Especially with dedicated encoders. (:
I can't change to nvenc even those i have a nvidia card
Go into handbrake: tools > preferences > video and check too see if allow nvenc is ticked, and make sure you have latest drivers for your nvidia gpu.
I have an 8700K and an Nvidia 1080GTX. The NVEnC option is about 6 times faster, even if using high quality mode. Thanks. Also, some of my older apps can't use GoPro H.265 files. If I use Handbrake to make it in to H.265 again some of my older apps can use the H.265 from my GoPro.
Hi Richard. I started using QS with the i7 4790K and have noticed as Intel introduced new CPUs that their QS encoder has gotten quicker. This isn’t always the case as Intel sometimes skip a generation before any noticeable changes. The same is true will Nvidia, from Pascal to Turing for example the NVENC encoders changed. This is probably why your results may be different to mine, as in the speed differences between QS and NVENC. In any event and as you’ve proven yourself, NVENC is quicker than QS when set to their slower best quality settings. You’re transcoding routine is very interesting, I’ve also noticed my GoPro H.265 files are problematic on certain playback platforms. Cheers, Dave.
How do I set the peak bitrate using vbr?
Can someone help me ? I am trynig to compress MOV file to H265 using handbreak, but when process end file is in mp4 and it only plays audio, not video showing. why ???
I been using NVEC h.265 on my 1050 ti for about a year (running a 2700x cpu) and on an average a 1080p movie takes about 12 mins. I am trying to find out if the NVEC encoder has improved enough on Turing GPU aka 1660 ti to justify the upgrade. Would you have insight to this question?
PS. Good video btw
Hi Brian. Yes the encoding has improved. I no longer have anything earlier than a Turing GPU so cant do a direct comparison, although I’m sure there’ll be some comparison videos on TH-cam. If you use OBS, there’s now an option for V2 for the NVENC encoder as well. Just so you know, there is no difference in encode speed between the 2080 I used in this video and a GTX 1660, they are both Turing and use the exact same NVENC encoder. Cheers, Dave.
Thanks so much for this video, was looking at the benefits of upgrading my GTX 760 card to a GTX 1660 Super for video encoding.. and it's been a learning process! The GTX 760 does not support h.265 encoding in NVENC, and I have learnt that lower bitrates in NVENC (on older cards like mine anyway), are not so good.
I used your video to put the theory to the test myself on a 720p60 clip in Handbrake, competing h.264 software encoder with the GTX 760 NVENC h.264 encoder - like your video, set to highest quality/slowest encode for both, and a low (2Mbps) average bitrate. The difference was like night and day.. yes the NVENC did it in 38 secs, and h.264 in 3 mins 23 secs - massive difference, but also was the quality - h.264 software encode was far better quality for the same file size.
I'm going to upgrade my video card still as I know the 1660 has a newer NVENC engine with better quality and h.265 support, and I may even repeat the test to see if quality has improved, but your video really helped, so my advice to others would be use NVENC on older video cards only if you're using a higher bitrate, otherwise if you can spare the time, use h.264 encoder in CPU.. it could be worth the wait for files at lower bitrates.
Hi Daz.
Thanks for the comment. As for X264, I do use this for low bitrate stuff. In fact I've been using for over 10 years now and have actually used it for some blue ray streams.
If you set X264 or X265 to their highest settings, which does take an age to encode, you will never get anything better for pure picture quality at the lower bitrates.
As this particular video was specifically for speed, I didn't want to use X264 or X265 in case people thought anything bad of them because it would have taken way way longer even compared to QuickSync. I may do a video soon showing how good X264 and X265 are for encoding low bitrate video. For that video I will also do downloadable examples.
Overall though, for anyone using moderate to high bitrates, there's no real reason to use X264/X265 as the differences in picture quality between all the encoders becomes almost indistinguishable and at that point and it's probably better to get the job done faster to save time.
Cheers,
Dave.
@@DavidHarry Thanks Dave, I now have a GTX 1660 Super and have re-run my encoding test. For the benefit of your viewers I can confirm that although the new NVENC is still not as good as software h264, the encoding speed was significantly faster (more than halved the encoding time), so for med-high bitrates, definitely go for hardware encoding if an option. Regards, Daz
Nice one Daz, thanks for the update and extra input, I’m sure it will be useful for others and a great choice for your GPU. I’ve got the standard 1660 and it’s perfect for NVENC encoding, the Super in my opinion is the best value GPU out there for the balance of gaming and doing some production stuff. If you’re into OBS your new GPU will also give a second, newer option for NVENC h.264 encoding. I use this all the time for recording game play, not streaming, and it’s immense. Cheers, Dave.
I'm looking to upgrade my video card from a GTX 720 to 1660 for x.265 NVENC encoding because I'm getting tired of watching my i7 CPU take 2 to 7 hours to encode a single movie while running at 99% and almost overheating the (CPU 72c / 161 f CPU temp!)
Yeah! I see his FPS was over 50 and my CPU is working its bits off to crank out a measly 7 to 12 fps.
I can see you use 100,000 avg bitrate for 4k, What average bitrate should I use for 1080p @ 30fps?
What’s the output for?
@@DavidHarry Lossless Movie file Recorded using OBS lossless preset in simple mode - the original file highest quality option is 6mbps
I meant what was your final HandBrake file going to be used for, as a TH-cam upload or just as a final viewing file etc. Plus, if you’ve started off with something that’s sourced at a low bit rate such as 6mb/s then it’s debatable that you’d need much beyond that as your final output from Handbrake, as you won’t really feel the benefit of a higher bit rate as you would if the source files were of a high bit rate. If you checkout some of my other videos and watch them in 4K, you’ll see that they maintain quite a bit of quality because I use high bit rates all the way from capture, editing, intermediate, final TH-cam upload and then when TH-cam does the last encode to its lower bit rates. If you go to www.TheGameThing.com this will take you to a channel I have that I’ll be doing some gaming videos on, at the moment it has a bunch of test encodes. Some of these are at 200mb/s and uncompressed for their uploads for the 4K/60 stuff. The higher the bit rate, doesn’t always translate to much better final quality at the TH-cam end. With video encoding, especially for game play or graphics based video, it’s massively diminishing returns with high bit rates. Cheers, Dave.
Handbrake not only uses pure HEVC hardware from Video Graphics Card, but also CPU too, so title might be misleading....
The title is not misleading as it clearly says that NVENC and QS are being used, it says nothing about X265 because I’m not testing for any software solution, only hardware assisted acceleration.
bros pc is damn...my hd 21sec clip took half an hour to complete encoding
My dual core PC took 22 minutes to convert a 4 minute 1080p 580mb video. :/
Need to try this test again, but this time use AlderLake...
Your advice how to record 4K on Android (Snapdragon mainly)?
so how movie release scene / pirated movie scene convert the movie into small 3-4 gb file with very clear quality but the size very small
Quicksync size will be atlead 30-50% smaller than nvidia/amd encoders
I am just looking at shrinking existing videos with very little if any loss in quality.
XMedia Recode has 4:4:4 chroma subsampling (full RGB) and that makes A LOT of difference in image definition and color accuracy (if your original file is 4:4:4). Handbrake doesn't have that option.
That makes absolutely no difference to anything with 4:2:0. You don’t increase colour range just because something is capable of higher sub sampling.
@@TheGameThing
I does make a lot of difference.
I've converted a 2.K video with the same bitrate from MP4 444 to MP4 420 and red lines on the video became blurried.
No it doesn’t. You can’t increase colour sampling beyond what the recording was. You may have seen something that helped your particular file but it definitely was not an increase in colour sampling. Besides. This video is showing NVENC and QS, this has nothing to do with Handbrake’s ability to process as handbrake is only a host GUI controller for the NVENC and QS encoders.
@@TheGameThing
My original file is 4:4:4. So yes, it does make a difference when I try to downsample it.
The problem with Handbrake for me is that it doesn't have a 4:4:4 option, while XMedia Recode has.
Your 444 file won’t make any difference in either NVENC or QT, neither will processing that chroma sampling space with regard the output. So, once again you are wrong about Handbrake, in this video as it does nothing with regard sub sampling. Everything in this video with regard video processing is handled natively by either NVENC or QT, not Handbrake. You really need to understand what you think you are criticising before commenting and getting it wrong.
I was wondering if the 3060 could encode h.265 and AV1 (like if I was to convert some videos from one format to either of them. It would not make or break a sale by any means. I just wondered if it or any of the 3000 series does it. I am just trying to find a price that won't make me have a heart attack and the 3060s are not too horribly overpriced (though they should be $300 cards).
Hi David, I am using a 3rd generation i7 3770 Non K CPU with 12gigs Ram and recently installed Geforce GTX 1660 Super and I am able to use H.265 NVENC in Handbrake Application. But as per spec sheet on Nvidia gtx 1660 super encoder can encode HEVC 8 bit and 10 Bit on HW acceleration including B frames.
Could you please advise how can encode H.265 NVENC with options 8 and 10 bit along with B Frame between 3 to 7
can we have H.264 and using older gen nvenc , because in RTX series they did buffed it up a good amount , so on gtx 1080 ti the encoder is slower. so if possible maybe a 1080 ti or 1080 vs qsv h.265+ 2.64
Great test!
sir should i buy Ryzen 7 2700 over i5 9600K ?
if you plan on upgrading
@Danica Daniel thank You Sir. For Only Secondery Monitor Should i buy GT 1030?
@Danica DanielEspecially for rendering on Premiere Pro and Edius
@Danica Daniel Thanks a lot Sir
That was fast for 4K. I am using a cheap Win11 laptop with 4GB RAM, often it takes about 30 mins (sometimes upto an hour and half) to encode a 20 min AVI raw file capture at 720x576 from a captured analogue tape using the H.264 encoder, setting at a bitrate of 8000kbps, 25fps and at the fast speed setting. My processor must very slow lol. I'm guessing I need something like an I7 processor with at least 16GB RAM.
What processor do you have?
@@royaleagle3756 It's only an Intel Celeron N4020 CPU. 4GB Ram
Intel QSV massively bloats my files for some reason. Like, ten times the size.
Hey David thanks for such an informational video. I dont havemuch knowledge about video encoding so pardon my silly
question. My video is a 1080p 30 fps OBS recorded mkv file Size 650 MB, my PC specs intel i7 7700HQ and nvidia 1050ti. i followed your video and for NVENC i used the following settings : web optimized "constant quality" at 24 and "optimize video" at slow encoder preset and when i run it it did the whole encoding work and finished in 1 minute(insane!) and final size was 80 MB But when using the intel 10bit QSV settings with quality at 24 and "encoder preset" at Quality i am getting the final output in 8 minutes(which is 8times of NVENC) but the final file size is 40 MB(half of NVENC final file).so is there any way i can reach a middle ground here with a little bit of more time consumed i want the file size to be reduced too like the intel qsv. what do you suggest i should do i plan to use the file for my consumption and uploading on google drive ?
Hi. My settings don't use CQ I use a fixed bitrate, CQ can be different depending on the codec being used. Try using a fixed bitrate using NVENC and maybe try a fixed bitrate VBR with other codec options. Somewhere in there you'll find the happy medium between time and size. The thing with this type of stuff is that it's not really worth one person advising another person on things such as bit rate etc. For instance, I'm prepared to wait for long encodes so I can get maximum quality at a given bit rate, most people don't want to do that. Just do some short 1 minute encodes with your average type of content to see what bitrates suit you. Cheers, Dave.
Nice. Can I ask? Why use Handbrake?
Hi Ray. It's free :) Plus it also uses the excellent X264 and X265 encoders and fairly straight forward to use. Cheers, Dave.
@@DavidHarry Thanks, Dave. There are so many questions I have with your explanation underneath the video that I'm going to have to go away and try to get them in some form of sensible order before posting them.
Hi Ray. When you've got the questions we'll chat about it on the Osmo forum, it may help others there. There'll be another video shortly, I'm just waiting for TH-cam ti render the UHD stream. Cheers, Dave.
@@DavidHarry Ok Dave. Will do it there. I've not long finished an 11-hour working day so turning in now. I'm out again at nine tomorrow morning. Will get onto it as soon as my brain has time to settle down.
Final file sizes? Image quality comparison? This was not helpful at all...
Which part about “speed test” did you not understand?
not the speed i am looking for ,the size of the files /nothing shows so far /congrats
Dude when you set the bitrate too high like 100000 you kill the purpose of experiment. The encoder time is mostly employed by compression algorithm. When you set it too high, encoder just skips the serious part of the compression job and dumps the data straight to the output file. For a 4K video, 50000 Kbit/s means high quality even with h264. You are using h265 which needs less bitrate for the same Q.
GPU nvenc H265 encoding is the best option for speed and quality
.
you can not encode with nvenc and quick sync with only one monitor output, you should have 2 separated video signals, one from nvidia, and the second one from intel cpu itself......, in my case, quick sync is 8 times faster than nvenc 3060, because i have 2 monitors, one hdmi pluggin in to my IGPU, and one to my rtx
This video didn't say anything... I would want to see filesizes of outputs. Also pure CPU would be necessary for the benchmark. Basically you would get Nvenc faster, but higher filesize, while cpu is slowest and lowest filesize. QSV is optimal bettween speed and filesize, which is in between. 4k with 100 MBit is an overkill. 24MBit is what I would use on 4k HEVC. Maybe you have 8k camera? And also when you use NVENC it removes BT2020 colours, and converts to BT709. YOU HAVE TO USE PURE CPU to preserve your colour quality, otherwise you are just wasting time... Maybe newest gpu can preserve BT2020, but it needs lots of testing to find out...
This video said exactly what the title said. It’s you who didn’t say anything and your ramblings just show your inexperience with encoding.
Why is the color space is being altered using NVENC and not on a CPU? Nvidia GPU's don't have any clue about HDR (rec/bt2020) or SDR (709), they simply use NVENC10bit 4:2:0. ..
good video!!!
Hi. Thanks for the comment. Cheers, Dave.
GPU encoding is usefull only for reltime encoding when space is not a problem. Because I tested CPU x265 slow encoding and nvenc quality encoding : the result is that nvenc need more than 2 times the space x265 need. If you want quality at not very very high bitrate, GPU is not the solution. Speed or quality you have to choose.
GPU is better than X265 when file size is not a factor as you can encode way way faster and high bitrates there is no visual difference between GPU and X265. Don’t forget, this video had absolutely nothing to do with CPU encoding and therefore nothing to do with X265, this video was clearly all about the speed differences between two hardware technologies, NVENC and QSV.
@@DavidHarry OK but people should remember that compression means saving space on disks. A compression that do not compress (as deeply than x265) is not a very good compression. So hardware compression is only for realtime compression (that will need a real CPU compression after to divide by 2 the file size). This need to be said to avoid people think there is a solution where there is not. I bought a nvidia card to compress my vidéos (films). I saw I got a 2 times bigger file size than with CPU encoding. I stopped using GPU. If people told more on social networks that GPU encoding means a 2 times bigger file than CPU encoding to get the same quality, I would not have mistaken. What a pity GPU encoding do not enable us to get the level of quality we want (I would prefer a 5 times slower compression with x265 like result). perhaps because it is not doable with GPU that is not as smart as CPU.
Video compression is not just for saving space on disk and making files as small as you can. If that were the case and going by smallest must be better, as you are saying, then X.265 wouldn’t be that good either because certain VP9 and VC1 encoders beat H.265 files produced by X.265 for file size. Plus there are other proprietary codecs that beat X.265/H.265 for file size. Like I’ve already said, this video and it’s title are clearly talking about hardware encoders, not software encoders. Keep an eye on my channel as I will do a video soon comparing X.265 and NVENC for the smallest file sizes. I’m sure you will like this comparison as it will clearly show what you are saying, X.265/H.265 encodes very clearly win in picture quality at small sizes VS NVENC but that comes at a massive cost in time.
@@DavidHarry in fact it depends on what people call small size. For me small size means below 10 000 kb/s in 1080 for h265 (8 to 10 GB for a 90 mn film). But even at 10 000 kbs, x265 slow beats hardware encoders by far (I have tested, no comparison possible). I think I would need 100 000 kbs to get an equal quality (I have not tested because it is not interesting for me).
Can you tell what you call small size in kbs ?
If you are not prepared to test for yourself, then how can you possibly give any numbers/figures. Your numbers are nowhere near accurate. You’re the one who mentioned the word small but your version isn’t that small.
Qsv is faster with Intel processors designed with iris plus graphics, the one used in this test is a gt2 or HD graphics processor which wasn’t designed for encoding or gaming. I have a several year old intel NUC “skull canyon” that would be faster since it has 72 execution units. Here’s a list of your looking to support 10 bit encoding at the fastest possible speeds. en.m.wikipedia.org/wiki/Intel_Quick_Sync_Video also this one en.m.wikipedia.org/wiki/List_of_Intel_graphics_processing_units
Not only are you wrong about what was used and the type of QS chip it has. The amount of execution units has nothing to do with the QS processor.
David Harry if you follow the second link I provided, the 9900k is a 2018 coffee lake with GT2.
But you don’t understand that the GPU power itself has nothing to do with the encoding speed or quality.
@@DavidHarry you were right. I ran a test with my i7-6770HQ and it was 15fps. So is the quick sync portion of the chip independent of the rest of the GPU? It appears that Intel hasn't updated this feature except to support 10bit encode.
Hi. Yes, that’s right, the QS encoder is a different part of the architecture to the rest of the GPU. You mentioned the execution units earlier and yes, they do make a big difference with pure GPU tasks between different Intel iGPU versions but many tend to have the same QS chip. I use Intel based PCs for running versions of Android on PC, basically AndroidX86 variations. I use this for Android game play and different versions of Intel CPUs with their iGPUs will play games better the more powerful the CPU/iGPU but will still only be about the same for encoding when under Windows with anything that takes advantage of QS. Intel’s QS encoder has changed over time but not much and not as often as Nvidia and their NVENC encoder. Nvidia put more effort into NVENC than Intel do with QS. The latest version of NVENC is actually the same on an RTX 2080 ti as it is on the GTX 1660. Which is great news as the 1660 is way cheaper and just as fast as a 2020 for encoding, obviously the CUDA core count and GPU power of the 2020 are way ahead of the 1660 and will leave it in the dust for game play etc. but at least Nvidia have put a great encoder even on their cheaper cards. In fact, even an old GT710 can do H.264 via NVENC, I think that was Maxwell architecture and you can pick one of those up for less than £30 new and it will be faster than Intel QS doing H.264 HD, I can’t remember if the 710 does UHD/4K. Cheers, Dave.
NVENC is the fastest, but the final file size is uuuh when QSV is slower, but final size is good.
Thank you, Dave!
Hi. You are very welcome. Cheers, Dave.
Thanks for the info. Now I've changed my video library compression from H264 with half the video time length for compression (for a 2h movie, it lasted ~1hour) to H265 with 6 min transocding :) Very nice!
H264 can have GPU support too! Learn NVENC website!
So a dedicated Nvidia graphics card outperforms integrated intel graphics. Well no one saw that coming!
And you don't understand that this has nothing to do with the GPU. You never saw that coming....
@@DavidHarry Care to elaborate? NVENC is "a feature in its graphics cards that performs video encoding, offloading this compute-intensive task from the CPU". That means the GPU does the encoding, So I think it has absolutely everything to do with a GPU.
Source: en.wikipedia.org/wiki/Nvidia_NVENC
NVENC is separate tech to the GPU, just as QS is to Intel or AMR to AMD. That’s why it has nothing to do with the GPU, the GPU does not accelerate the encoding. Further proof is when you put a RTX 2080 up against a GTX 1660, they both encode at the same speed yet the GPU in the 2080 is way more powerful. Again proving it’s not a GPU related task but a task assigned to a separate DSP processor that’s conveniently on the same GPU board that is designed to do only one job only, encode video.
Not obvious to me. One would think the processing power of a CPU is much more powerful than that of a GPU. A CPU is basically built solely for calculations.
Nice PC set up you have there. :)
I hope Premiere pro nativly support NVENC someday...
Hi Tide. Prem was my first NLE about 25 years ago, I've always had a soft spot for it, first love :) I haven't used it in a very long time and didn't know that it doesn't support NVENC, which is a real shame as it'd really help. As for the PC, I'm just finishing a bunch of videos about its build. I'll post those on the DJI forum as they may be useful for Pocket and Action owners. Here's the intro to the main video in that set, I got my 8 year old nephew to give me a hand for the intro :) th-cam.com/video/6-dqLmuqwZw/w-d-xo.html Cheers, Dave.
Which Premiere Pro Tide?
I am using Adobe Premiere Pro 13.1.4 (Build 2)
Hi Dave, Premiere supports Quick Sync but not yet for NVENC.
I am interested to check out the PC build. 😊 Pocket or Action's 100mbps file is not easy for CPU and memory to handle on timeline playback. Cheers! 👍
Install VOUKODER plugin (NVENC with h.264 and h.265)
Encoding time is not everything. Maybe NVENC has worse pic. quality but faster. We don't know :D
The title clearly says SPEED TEST, it has nothing to do with quality.
Quicksync is terrible, files are always huge, the quality is always horrendous, artifacting is an issue. Nvenc actually works...
But I'd rather use the CPU as speed isn't my number one priority.
Pretty confuses w ur accent
Liverpool England.
Completely useless. No comparison of file size or quality... Waste of time.
*How can i play 4k ultra hd format on my lcd through USB? I added 4k preset and encoded in handbrake but still the video didn't play on tv*
Make sure that whatever is playing the file is actually compatible with the file and its video and audio codec. Can you play the file back on the computer that you encoded it on? If so, this means that there is no problem with the file and the problem is with your player or display. Cheers, Dave.