Stupid question here....... ¿youtube do not re-encode the video... making all this job pointless???....... I mean .. when I use the "download MP4" option in my youtube CreatorStudio.... the file that i download there it is not the same that i upload...... even uploading MP4... it get's re-compressed.. And wen you upload AVI.. 720p video... it finish with better quality than 1080p... because youtube compresses it less... Anyway.. people watchit in a 15cm screen... and in portrait mode.... so 7cm wide x almos 4cm high ja ja ja...
I used handbrake took 4 hours VideoProc Converter ai took 1 hour. And quality was better this is frustrating for me because I hate windows looking at running it under wine but don't have any real hopes
Hardware video encoding is also used for wireless displays. I remember when Intel's QuickSync was introduced, Apple made a fanfare about the Macbooks now supporting fast screen mirroring with Airplay (which on PCs is now miracast)
I knew about hardware accelerated encoding, but I still wanted to know some more about it; I'm happy I watched this video. Didn't know there was actual circuitry doing this. Great video!
I don't really get why more people are working in 4K and higher when at the same time more people are consuming content on mobile phones and tablets with smaller screens. It seems contradictory. People put themselves through hell with constantly transitioning to new hardware, software, methods, and increased export times, that ultimately offer very little real-world gain. I'm pretty old-school with common sense and reasoning and to be honest I wouldn't bother using anything more than 720p. Depending on the type of encoding you use it can look as good as 1080p or higher in some cases anyway.
You say that now, but if you're producing a video that you want to look great in the future you have to produce today to keep up with future advancements in tech. Don't believe me? Go watch a 240p video from the early days of RUclips. haha
I’m a cyclist and I bring my GoPro Hero 5 camera along each ride. I’ve been using Handbrake for a few years now to “crunch” the file size to a more manageable size. It saves money spent on storage drives. I recently purchased a Mac Mini M1 out of curiosity. I was able to find a beta version of Handbrake that’s optimized for the M1 hardware. You can encode either single or dual pass mode. In single pass mode, it’s faster than my PC equipped with an Nvidia RTX 2060. The quality, however, is inferior imo. When I set it to two pass mode, the quality is significantly improved and in my opinion is better than encoding with Nvenc and Handbrake. The files sizes are almost identical. It is slightly slower, but the improved quality makes it worth the wait. The Mac requires less power (wattage) and runs silent. I’m a PC guy, but this Mac has impressed me enough to mention it here.
I would be curious which of the various encoding formats (e.g. H264 vs HEVC) resulted in the video being available on RUclips the quickest. Sure HEVC will have the smaller file sizes and thus will result in a quicker upload, but remember RUclips still has to take that Video and do its own post-processing on it in order for it to be available at the various Quality formats available. I suspect we have all encountered that scenario where we've uploaded a 4K video to RUclips and whilst 420p and lower quality settings were available it took some time (perhaps hours even) for all that quality formats to become available since RUclips must do its own processing there. Another thing to keep in mind is that with HEVC you're trading off video encoding performance for smaller file sizes but also faster decodes. One of the stated purposes of HEVC was to make high resolution accessible to low power devices like smartphones.
Quicksync is why I stil use my old 4th gen Core i3 processor for basic video editing because it can still handle and render 720p/1080p videos for mild usage
I recently upgraded my desktop PC GPU from a GTX 970 to a GTX 1660 Super. Using Vegas I noticed an increase in performance in video editing of about 25% for rendering files. I tried both small (under 2 min length) and not so small (about 45 min length). The thing that is probably mostly affecting any performance difference in my case that the 1660 Super uses a newer engine which is performing much better (NVENC). In speed in vegas about 25%. But I also noticed a huge difference in streaming (twitch) video quality where using the 970 (nvenc again under obs) provided definitely easy to notice pixelated video compared to the 1660 super. The GPU you used is as far as I remember, also using the same as the 970. I do wonder if a 1660 (or higher) GPU would get a much different result in your case. Obviously not something you can test as you have a laptop, but it still interesting to think about it. Unfortunately my CPU doesn't have qsync so I couldn't test them with that too. It's a i7 5960X. Thanks for the video.
It is really only in realtime encoding hw acceleration is useful. The result is worse and files are bigger which is not good for a result you are going to save.
I have some chapters of a series in 4k that weigh 10gb each chapter. I want to convert those videos to 1080p and in the best possible quality. Could you give me your favorite Handbrake settings to see if I can reduce the size and keep it looking just as good?
One thing that was missing that I would have liked to see is comparing the quality of the results. You choose 22 constant quality with all the encoders, however from what I have seen on forums, different encoders will produce micro blocking and other unwanted artifacts, where others do not. Typically software encoders (x264, x265) produce a better quality image, regardless of the CQ setting you have set. This is something to consider since, in your example, you are going to upload your videos to youtube which again, will re-encode your video. Having the best quality as a source is important here. Garbage in = garbage out.
RUclips supports ProRes, and you can export ProRes from FFmpeg (using its prores_ks codec), so there's really no excuse for uploading H.264 or H.265 to RUclips unless it's intra-frame and perceptually lossless (QP=0 / CRF
I use FFMPEG which is what HandBrake uses internally. I specify a target bitrate instead RF. When I do that, file sizes are consistent with bitrate and the length of the video in time.
The real solution is to get a desktop computer with full fat hardware instead of using potatoes like Macs and laptops with tiny heatsinks and clock limited silicon to match. That'll speed things up way more than any settings.
Holy smokes! Thank you so much... I was always wandering why my encoding took so long... handbrake always defaulted to Software.... you Sir just cut my rendering times down from two hours to ten minutes XD (Now to see if Openshot has that option as well)
Hey... you promised it was going to be nerdy? I think you forgot to include the nerdy part :D Just kidding, it’s an excellent piece of content, and you answered a set of questions that many have, but for some reason the internet doesn’t provide clear answers for.
Let me preface this by saying that my knowledge of video compression technology is very low. But from a layman's point of view, I disagree with the parameters chosen, particularly 'quality'. The yardsticks for measuring quality can't be software 'presets'. Instead, it would have been better if comparisons were made based on bitrate (as a measure of quality), along with compression time and file size. In other words, presets/compression settings could have been chosen such that they achieve a specific bitrate; then, comparison becomes one between compression time and file size. Alternatively, settings could have been chosen to aim at a specific file size; then comparison/tradeoff could be between bitrate and time. As I don't have the hardware, would love see the results of experiments conducted on these lines!
You have a decent point, but the quality slider in Handbrake uses software to analyze the frames of video during the transcode to dynamically adjust the bitrate for each scene. It is possible to get a high quality result with both methods, but the quality slider saves you a lot on filesize in the output file. I find it the easiest method for compressing my bluray collection because if I decide that quality setting 24 doesn't look good enough for one movie, I can take another stab at it and up the quality of the finished file in a meaningful way all while maintaining a small filesize.
Every intermediate encode you do is going to cause quality loss since it gets re-encoded over and over on the path to getting up to youtube. It's usually a better idea to just bite the bullet and upload the source video at the highest quality you possibly can.
Thank you so much!!! your video really helped me save a lot of time. Though I use handbrake to embed subtitles to video but the process is pretty much the same.
I've always had a massive pet peeve about using quality based encoding, I prefer knowing exactly how big something will be, it genuinely pisses me off when an encoder doesn't have an option for set bitrate, I know that it's the inferior way to do it from a file size perspective, but I do it anyway.
Although this is a very good video and gone through a lot of what QSV and NVENC do, there is also one more thing: even with the same RF 22 chosen in handbrake, the final result would still be different in quality. You'd need to use something like Netflix's VMAF to quantify the output's quality to ensure the encoders are generally achieving the same thing, with all the differences in performance and file sizes
Just fyi, both handbrake and OBS use ffmpeg under the hood to be able to do software and hardware encoding. Ffmpeg is a command line utility. But you get a lot more options. Also, from reading, I've seen people saying that hardware encoding produces lower quality videos. Not sure how true this is. Even if true with the time benefits, you may be able to still get something better and increase the quality more than you would with software encoding.
Great review with some solid data, thank you for the neat watch! I did these test too maybe six months ago for my personal Blu-ray collection and I was shocked how *bad* HW encoded movies looked. Regardless of settings (RF 18-24, fast to slow) color banding and blocking was so bad I just went back to SW encoding. Did you notice any quality problems? I assume not since you would have mentioned them.
Nvenc and the other hardware encoders are a godsend for streaming games, but it doesn't make much sense using it for handbrake, unless of course you have higher end hardware. I'm not sure for Intel, but the image quality nvenc produces, increases the more powerful the graphics card. Nvenc is for speed first and foremost which is why software encoding will always produce the best image quality.
You're missing out. Check your Mac. It's T2 security chip is basically a iPhone CPU with it's hardware video encoding. Use HandBreak and use "Video Toolbox" under video encoder.
Sorry, but you're making a HUGE error. The Constant Quality number are NOT consistent between different encoding methods. So 22 using software is NOT the same as 22 using QuickSync or Nvidia. I think it even says this when you mouse over it. You have to check the kb/s and match that.
The results are similar because: 1. Video quality is not considered in the comparison table 2. Decoding happens on the CPU, and it´s a bottleneck in this case
Latest Adobe Premiere version should support hardware encoding when exporting. Resolve and Final Cut have supported it for a while now. Also, in my experience the transcode quality using the same settings goes like this: NVENC > Quick Sync > VCE
I usually transcode 720p or below. H265 is just too demanding for my system. So I stick with H264 and software encoding for smaller file size. With 6core CPU like old Xeon, the encoding speed is actually not bad.
Out of interest how did the files look during playback after encoding. I remember a few reviews looking at the technology several years ago stating that Nvidia and AMD both sacrificed some quality for the speed gains when encoding. Software encoding was by far the clear winner in terms of quality but Quicksync did seem to offer a great balance between speed and visual quality in the result. I wonder if this is still the case or has Nvidia made big strides in this area, especially with the rise of Twitch and trying to stay ahead of AMD and Intel
90% of RUclips videos are watched in 720p/1080p using smartphones with a limited data cap, why even bother uploading it in 4k. People only download and watch 4k videos if it's a movie anyways.
Amd VCE converts 3hour 3gb vid down to 1.3-1.4gb in h264 around 17mins However with av1 it's an hour but filesize is 300-400mb with the same image quality
Even HEVC playback is a stress-test without hardware decoding. 😕 My decade-old laptop can't play h.265 (at least not 720p videos, and especially not at 1.5x+ speed which I watch everything at). But, I'm still amazed by its performance with such small sizes at such high quality and resolution. I wish I could remember the name of that new codec that's coming out soon that will put even HEVC to shame (I'm fairly sure it's not h.266 VVC because they'd been using that name before I heard about this one).
when I did similar experiments in the past I didn't think the nvenc/quicksync files looked as good as software encoding.. did you visually confirm they were 'the same' ?
They looked fine to me, with the caveat that the source files didn’t contain much fast motion (which is where compression artifacts most commonly show up). Which encoder (and quality settings) to use can sometimes be dictated by what you’re trying to compress - I’d use the software encoder and a more generous RF value for an action movie, for example.
On Macs with the t2 chip, the hardware acceleration is pretty amazing
2 года назад
Let's say I have a lot of old gameplay footage that takes up too much space due to nonesensical high bitrates during recording. I don't use them, but want to keep them at a resonably good quality and small file size. In that case, I assume that software encoding H256 would be the best option in handbreak? Or am I wrong? It doesen't matetr how long it takes or how slow the encoding is, priority are a small file size while keeping a reasonable quality that doesen't look too bad when watching those old recordings.
Another tip, Macs with the T2 chip can also do hardware H.265 encoding (through whatever software that supports "Video Toolbox", the macOS video encode/decode API).
So this kind of reaffirms my conclusions from the last time I looked into hardware-accelerated handbrake encoding vs software encoding-a conclusion I made years ago btw. Still, I wondered if things had maybe changed since I last looked into it, but I guess we're still CPU-bound if the hope is to achieve high-quality video with small sizes over a speedy workflow. I still have this one super specific question left. Will an outdated CPU like my i7 2600 be outperformed by newer processors in areas other than speed? I know it's obvious that the new chips from Intel and AMD will be way faster at crunching the numbers, but when using the x265 software encoder in Handbrake will the output file from a modern processor be of any higher image quality, or more efficiently compressed?
When using software encoding, quality won’t change between CPUs - at that point the chips are just doing the math that Handbrake tells them to. You’ll only gain performance with newer CPUs.
So is it a bad sign if your video encoder maxes out to 100% all the time for live encoding, say with ShadowPlay or ReLive for instance, or does that mean it's working properly?
On Linux both video acceleration technologies are available (NVidia's NVEncode, and Intel's Quick Sync), and Hand Brake has a native Linux version that can be used. The OP's ThinkPad X1 Extreme has official Linux support (from Lenovo). Would the OP consider doing a Linux version of this video?
With my ThinkPad T480 (the Intel UHD Graphics 620 video hardware variant) running Linux Mint 20 the following video/picture acceleration profiles are available: - VAProfileMPEG2Simple - VAProfileMPEG2Main - VAProfileH264Main - VAProfileH264Main - VAProfileH264High - VAProfileH264High - VAProfileJPEGBaseline - VAProfileJPEGBaseline - VAProfileH264ConstrainedBaseline - VAProfileH264ConstrainedBaseline - VAProfileVP8Version0 - VAProfileHEVCMain - VAProfileHEVCMain10 - VAProfileVP9Profile0 - VAProfileVP9Profile2 Based on the above profiles most of the major media (pictures, and videos) that use the more modern codecs would be supported through hardware acceleration.
MAC - weird with the mac in the back you didn't talk about macos- handbrake didn't used to support quicksync on macos for example. It now supports 'video toolbox' but its a blackbox. so what it uses under the covers is hidden unfortunately.
Pirates spend money on PC's too. So yeah, Intel should think about it. No matter if what it is being used for is legal or not. Money is Money. And not everyone will use it to shrink pirated videos.
OK one thing - why change Matroska for MP4? Seems like MP4 doesn't help make the file smaller or that Matroska should have any issues for RUclips to process
For the performance tests, you’re right, the container isn’t relevant. I switched it anyway simply because if I hadn’t, there’d undoubtedly be comments from people saying that my testing wasn’t consistent.
currently doing some tests with AMD VCE. My RX 580 is definitely faster than the Ryzen 5 3600, I'll need to test my GTX 1080 and RX Vega as well. got a 1.1GB file down to 160MB on software, and 485MB on the 580's VCE.
I am using h.264 NVEnc at 23.977 FPS, quality 18 and audio pass through with video crop on i7 processor with 4 cores and nvidea gtx 1060, it is processing around 100 fps, GPU at 30%, cpu at 52%. Is there a way to improve performance?
Drive performance and RAM are largely a non-issue when it comes to video transcoding, interestingly enough. Processing power is the bottleneck by a very wide margin.
@bashful Fun question, but it makes total sense. He peaked around what, like 120-something fps in the fastest encodes? How big do you think a 120 frame video would be? Memory and storage speeds can maintain that rate all day. The x265 encodes are even slower than that, so it's even less work for the memory and SSD to keep up with.
So I'm using a GTX 960 and Intel 2400. Both generations are too old. Nvidia requires 10th gen or newer. Intel quire's quite bit newer. The fact that Linux acceleration only works from handbrake cli makes the entire thing a no-go for me. I'm looking to upgrade to a Ryzen 5 3600 to just brute force it.
I have some chapters of a series in 4k that weigh 10gb each chapter. I want to convert those videos to 1080p and in the best possible quality. Could you give me your favorite Handbrake settings to see if I can reduce the size and keep it looking just as good?
Hi good night my name is ricardo don't know if u can help me out with my problem (handbrake) i have a TV series i want to converted from MKV to MP4 file d length is 43:39 d file size is 1.30GB MKV file after i converted to MP4 file i am getting 431MB is that correct thank u stay safe be safe out there
Hey, multiply 1080 by 2... you get 2160. 4K is only two times of 1080. That's sadly a marketing lie since they used the horizontal number (3840, rounding it up gets you 4,000) instead of the vertical (2160) as we used to. We had 144p, 240p, 360p, 480p, 720p, 1080p, 1440p, but suddenly they ditched this fine system and went with the marketing schemes
I stumbled across your video because I was trying to answer a similar question. However, when it comes to size issues with NVEnc, did you happen to see this thread? github.com/HandBrake/HandBrake/issues/2231 If I'm reading it correctly, it sounds like we shouldn't use the "Constant Quality" setting because 1) a particular number can mean different things to different encoders, and 2) "[Constant QP] unnecessarily wastes disk space and should be avoided!" We should probably be using the "Avg. Bitrate" setting instead. In your case, you can try to hit RUclips's recommended bitrates, support.google.com/youtube/answer/1722171?hl=en. In my completely unscientific testing, I found that I can set an average bitrate for an NVEnc encode that matches a software encode set to CQ 18 or 22 and the result is nearly matching file sizes and no difference in video output that my eyes can detect.
I understand this video is 3 years old and you are using old hardware even for 3 years ago, It would be cool to see an update on the numbers using current gen 14th gen Intel and 40 series GPUs. My current system is a 13900k with a 4080 super and I've been using Handbrake to make my content for my Plex server smaller. My Rip of Fellowship of the Ring was 113gb at 4KUHD and almost 87mb/s bitrate... Yes, this video needed to be compressed. Software H.265 would have taken 4 hours encode! I could have watched the entire movie waiting for my encode LOL! I ended up using NVEenc and that took 45 minutes, but It drastically reduced the filesize to an acceptable 40gb and 12MB/s bitrate. The newer hardware clearly added file size reduction..
After a long time very recently I once again tried Handbrake to rip one of my DVD's (indeed using hardware acceleration), but this didn't work out at all, since only the first chapter (or only parts of it) were encoded. Other Chapters didn't even show up in Handbrake, something which still worked some years ago. But some years ago I dropped Handbrake completely, when they dropped support of one of the video container formats. Now I don't use this format anyway, but I never went back to Handbrake. Since then I'm using FFmpeg (installed/updated like many other OS tools that I use via MacPorts) straight from the Terminal for pretty much any encoding job (AFAIK Handbrake and similar tools are just fancy frontends that are using FFmpeg nevertheless). Since I'm using a Mac first I tried hardware encoding via the Elgato H.264 HD dongle and it's horrible software when FFmpeg didn't support hardware encoding yet. But using FFmpeg's h264_videotoolbox Codec for hardware acceleration on a Mac (hevc_videotoolbox/h265 hardware acceleration isn't supported by my MacBook Pro from '15 which btw also will be my last Apple device since I'm getting a better servicable/repairable Linux-only Laptop next) is just so much faster, better and has a higher quality then Elgatos horrible software and hardware. But usually I convert my SD recordings from TV (recorded using a Dreambox 8000) via software encoding with libx264 and the HD recordings via the hardware accelerated h264_videotoolbox (btw. audio transcoding can also be done hardware accelerated via aac_at (at stands for audiotoolbox I guess?), but I haven't found an option for this is Handbrake's audio settings/Codecs). also 2:51: But I'm kinda curious if this can be solved too via the above mentioned method of using pure FFmpeg. I doubt that my machine supports this, but reading the documentation of the various Filters of FFmpeg I noticed that there are some variants of more common filters i. e. for scaling that also use hardware acceleration (via CUDA). For instance beside the already mentioned "scale" filter there's also an optional scale_npp filter (ffmpeg.org/ffmpeg-filters.html#scale_005fnpp) that seems to use NVIDIA Performance Primitives (libnpp) for doing the scaling in hardware. But there are more filters with hardware acceleration support like transpose_npp, overlay_cuda or yadif_cuda (for hardware accelerated interlacing).
100 MB for 84 minutes is going to mean you need super low bit rates. H265 will yield better video quality than H264. First of all, dial down the audio bit rate as much as possible but don't completely sacrifice it. If you are going to be playing on a modern computer then use a low bit rate mono Opus soundtrack (16 or 24 kbps), otherwise use mono 16 or 24 kbps AAC+HE if your playback device can understand AAC+HE. Failing that, you'll have to use AAC-LC mono at 32 or 48 kbps (or VERY aggressive VBR MP3) to retain any fidelity. If picture content is mostly film/video sources, at the very least you'll need to tune for film and do an aggressive two-pass encode. Likely a two-pass ABR-VBV is what you'll need. I'd also play with more complex B-pyramids and longer runs of B frames (as much as your chosen H264 profile and level will allow -- or more if you're willing to produce a noncompliant file to save on bits). Video dimensions will also be massively reduced. 100 MB minus a small amount for overhead and a 48 kbps audio track only leaves you about 120 kilobits per second for video. Even a 320x240 video at 24 fps needs about double your available bit budget. You can either reduce the video to postage stamp sizes or reduce the frame rate (15 fps at 320x240 will yield about 115 kbps video bit rate, plus audio). 84 minutes into 100 MB is one heck of a challenge!
nvidia encoder looks like trash during a lot of high transition scenes like in movies. Those encoders are for game streaming, video decoding like youtube, and video encoding for work (3d rendering, transcoding your movies, etc)
TL;DR for the impatient types: Use Quick Sync, NVEncode or VCE to make H.264 or H.265 video encode faster. There, I just saved you 16 minutes!
Good Guy Collin.
Charles Swanson II right now amd GPU dont have good enough encoder, just go brute force with more cores
love yours video update tanks..
Stupid question here....... ¿youtube do not re-encode the video... making all this job pointless???....... I mean .. when I use the "download MP4" option in my youtube CreatorStudio.... the file that i download there it is not the same that i upload...... even uploading MP4... it get's re-compressed..
And wen you upload AVI.. 720p video... it finish with better quality than 1080p... because youtube compresses it less...
Anyway.. people watchit in a 15cm screen... and in portrait mode.... so 7cm wide x almos 4cm high ja ja ja...
@@Ramdileo_sys thank you for your comment good day to you sir byby ..
I love Handbrake. It was a lifesaver when I converted old family videos to digital format.
Filthy pirate. 12:27
They were already digital before handbrake touched them.
I used handbrake took 4 hours VideoProc Converter ai took 1 hour. And quality was better this is frustrating for me because I hate windows looking at running it under wine but don't have any real hopes
Hardware video encoding is also used for wireless displays. I remember when Intel's QuickSync was introduced, Apple made a fanfare about the Macbooks now supporting fast screen mirroring with Airplay (which on PCs is now miracast)
NVENC has such a high bitrate because it's optimised for realtime encoded livestreams
I knew about hardware accelerated encoding, but I still wanted to know some more about it; I'm happy I watched this video. Didn't know there was actual circuitry doing this. Great video!
Damn, I finally found a use for the integrated graphics on the cpu..
I don't really get why more people are working in 4K and higher when at the same time more people are consuming content on mobile phones and tablets with smaller screens. It seems contradictory. People put themselves through hell with constantly transitioning to new hardware, software, methods, and increased export times, that ultimately offer very little real-world gain. I'm pretty old-school with common sense and reasoning and to be honest I wouldn't bother using anything more than 720p. Depending on the type of encoding you use it can look as good as 1080p or higher in some cases anyway.
You say that now, but if you're producing a video that you want to look great in the future you have to produce today to keep up with future advancements in tech. Don't believe me? Go watch a 240p video from the early days of RUclips. haha
I’m a cyclist and I bring my GoPro Hero 5 camera along each ride. I’ve been using Handbrake for a few years now to “crunch” the file size to a more manageable size. It saves money spent on storage drives.
I recently purchased a Mac Mini M1 out of curiosity. I was able to find a beta version of Handbrake that’s optimized for the M1 hardware. You can encode either single or dual pass mode. In single pass mode, it’s faster than my PC equipped with an Nvidia RTX 2060. The quality, however, is inferior imo. When I set it to two pass mode, the quality is significantly improved and in my opinion is better than encoding with Nvenc and Handbrake. The files sizes are almost identical. It is slightly slower, but the improved quality makes it worth the wait. The Mac requires less power (wattage) and runs silent.
I’m a PC guy, but this Mac has impressed me enough to mention it here.
I would be curious which of the various encoding formats (e.g. H264 vs HEVC) resulted in the video being available on RUclips the quickest. Sure HEVC will have the smaller file sizes and thus will result in a quicker upload, but remember RUclips still has to take that Video and do its own post-processing on it in order for it to be available at the various Quality formats available. I suspect we have all encountered that scenario where we've uploaded a 4K video to RUclips and whilst 420p and lower quality settings were available it took some time (perhaps hours even) for all that quality formats to become available since RUclips must do its own processing there.
Another thing to keep in mind is that with HEVC you're trading off video encoding performance for smaller file sizes but also faster decodes. One of the stated purposes of HEVC was to make high resolution accessible to low power devices like smartphones.
Quicksync is why I stil use my old 4th gen Core i3 processor for basic video editing because it can still handle and render 720p/1080p videos for mild usage
I recently upgraded my desktop PC GPU from a GTX 970 to a GTX 1660 Super.
Using Vegas I noticed an increase in performance in video editing of about 25% for rendering files. I tried both small (under 2 min length) and not so small (about 45 min length).
The thing that is probably mostly affecting any performance difference in my case that the 1660 Super uses a newer engine which is performing much better (NVENC). In speed in vegas about 25%. But I also noticed a huge difference in streaming (twitch) video quality where using the 970 (nvenc again under obs) provided definitely easy to notice pixelated video compared to the 1660 super.
The GPU you used is as far as I remember, also using the same as the 970. I do wonder if a 1660 (or higher) GPU would get a much different result in your case. Obviously not something you can test as you have a laptop, but it still interesting to think about it.
Unfortunately my CPU doesn't have qsync so I couldn't test them with that too. It's a i7 5960X.
Thanks for the video.
Awesome in-depth vid. Handbrake is a gem. 💯
It is really only in realtime encoding hw acceleration is useful. The result is worse and files are bigger which is not good for a result you are going to save.
I have some chapters of a series in 4k that weigh 10gb each chapter. I want to convert those videos to 1080p and in the best possible quality. Could you give me your favorite Handbrake settings to see if I can reduce the size and keep it looking just as good?
Thank you very much! This cut my 8hour long encoding time to 18minutes!
One thing that was missing that I would have liked to see is comparing the quality of the results.
You choose 22 constant quality with all the encoders, however from what I have seen on forums, different encoders will produce micro blocking and other unwanted artifacts, where others do not.
Typically software encoders (x264, x265) produce a better quality image, regardless of the CQ setting you have set.
This is something to consider since, in your example, you are going to upload your videos to youtube which again, will re-encode your video.
Having the best quality as a source is important here. Garbage in = garbage out.
RUclips supports ProRes, and you can export ProRes from FFmpeg (using its prores_ks codec), so there's really no excuse for uploading H.264 or H.265 to RUclips unless it's intra-frame and perceptually lossless (QP=0 / CRF
Wow. This footage is C R I S P Y.
I use FFMPEG which is what HandBrake uses internally. I specify a target bitrate instead RF. When I do that, file sizes are consistent with bitrate and the length of the video in time.
@thecouchtripper Probably so he has a predictable file size that's easier to upload over a slower connection?
The real solution is to get a desktop computer with full fat hardware instead of using potatoes like Macs and laptops with tiny heatsinks and clock limited silicon to match. That'll speed things up way more than any settings.
Holy smokes! Thank you so much... I was always wandering why my encoding took so long... handbrake always defaulted to Software.... you Sir just cut my rendering times down from two hours to ten minutes XD (Now to see if Openshot has that option as well)
Hey... you promised it was going to be nerdy? I think you forgot to include the nerdy part :D
Just kidding, it’s an excellent piece of content, and you answered a set of questions that many have, but for some reason the internet doesn’t provide clear answers for.
Let me preface this by saying that my knowledge of video compression technology is very low. But from a layman's point of view, I disagree with the parameters chosen, particularly 'quality'. The yardsticks for measuring quality can't be software 'presets'. Instead, it would have been better if comparisons were made based on bitrate (as a measure of quality), along with compression time and file size.
In other words, presets/compression settings could have been chosen such that they achieve a specific bitrate; then, comparison becomes one between compression time and file size.
Alternatively, settings could have been chosen to aim at a specific file size; then comparison/tradeoff could be between bitrate and time.
As I don't have the hardware, would love see the results of experiments conducted on these lines!
You have a decent point, but the quality slider in Handbrake uses software to analyze the frames of video during the transcode to dynamically adjust the bitrate for each scene. It is possible to get a high quality result with both methods, but the quality slider saves you a lot on filesize in the output file. I find it the easiest method for compressing my bluray collection because if I decide that quality setting 24 doesn't look good enough for one movie, I can take another stab at it and up the quality of the finished file in a meaningful way all while maintaining a small filesize.
Every intermediate encode you do is going to cause quality loss since it gets re-encoded over and over on the path to getting up to youtube. It's usually a better idea to just bite the bullet and upload the source video at the highest quality you possibly can.
Thank you so much!!! your video really helped me save a lot of time. Though I use handbrake to embed subtitles to video but the process is pretty much the same.
I've always had a massive pet peeve about using quality based encoding, I prefer knowing exactly how big something will be, it genuinely pisses me off when an encoder doesn't have an option for set bitrate, I know that it's the inferior way to do it from a file size perspective, but I do it anyway.
Although this is a very good video and gone through a lot of what QSV and NVENC do, there is also one more thing: even with the same RF 22 chosen in handbrake, the final result would still be different in quality. You'd need to use something like Netflix's VMAF to quantify the output's quality to ensure the encoders are generally achieving the same thing, with all the differences in performance and file sizes
Just fyi, both handbrake and OBS use ffmpeg under the hood to be able to do software and hardware encoding. Ffmpeg is a command line utility. But you get a lot more options.
Also, from reading, I've seen people saying that hardware encoding produces lower quality videos. Not sure how true this is. Even if true with the time benefits, you may be able to still get something better and increase the quality more than you would with software encoding.
Great review with some solid data, thank you for the neat watch! I did these test too maybe six months ago for my personal Blu-ray collection and I was shocked how *bad* HW encoded movies looked. Regardless of settings (RF 18-24, fast to slow) color banding and blocking was so bad I just went back to SW encoding. Did you notice any quality problems? I assume not since you would have mentioned them.
Nvenc and the other hardware encoders are a godsend for streaming games, but it doesn't make much sense using it for handbrake, unless of course you have higher end hardware. I'm not sure for Intel, but the image quality nvenc produces, increases the more powerful the graphics card. Nvenc is for speed first and foremost which is why software encoding will always produce the best image quality.
So...the big question...what settings did you use when exporting this crispy video?
You're missing out. Check your Mac. It's T2 security chip is basically a iPhone CPU with it's hardware video encoding. Use HandBreak and use "Video Toolbox" under video encoder.
Oh, and the T2 will encode H.265
Sorry, but you're making a HUGE error. The Constant Quality number are NOT consistent between different encoding methods. So 22 using software is NOT the same as 22 using QuickSync or Nvidia. I think it even says this when you mouse over it. You have to check the kb/s and match that.
The results are similar because:
1. Video quality is not considered in the comparison table
2. Decoding happens on the CPU, and it´s a bottleneck in this case
Latest Adobe Premiere version should support hardware encoding when exporting. Resolve and Final Cut have supported it for a while now.
Also, in my experience the transcode quality using the same settings goes like this: NVENC > Quick Sync > VCE
That shirt is great!
Really interesting and helpful! My kind of experiment
you can enable quick sync for decoding and nvenc or vce for encoding and use both gpu and discret graphic at the same time (handbrake options)
that would make encoding go brrr
Nice shirt by the way. Very nice.
I usually transcode 720p or below. H265 is just too demanding for my system. So I stick with H264 and software encoding for smaller file size. With 6core CPU like old Xeon, the encoding speed is actually not bad.
There's no reason to use anything above 720p for most people.
Great video!
Great video!
Thanks for sharing👍😀
Thank you for this video.
I learned alot, appreciate it! :)
THANK YOU SO MUCH
Out of interest how did the files look during playback after encoding. I remember a few reviews looking at the technology several years ago stating that Nvidia and AMD both sacrificed some quality for the speed gains when encoding. Software encoding was by far the clear winner in terms of quality but Quicksync did seem to offer a great balance between speed and visual quality in the result. I wonder if this is still the case or has Nvidia made big strides in this area, especially with the rise of Twitch and trying to stay ahead of AMD and Intel
90% of RUclips videos are watched in 720p/1080p using smartphones with a limited data cap, why even bother uploading it in 4k. People only download and watch 4k videos if it's a movie anyways.
Amd VCE converts 3hour 3gb vid down to 1.3-1.4gb in h264 around 17mins
However with av1 it's an hour but filesize is 300-400mb with the same image quality
Even HEVC playback is a stress-test without hardware decoding. 😕 My decade-old laptop can't play h.265 (at least not 720p videos, and especially not at 1.5x+ speed which I watch everything at). But, I'm still amazed by its performance with such small sizes at such high quality and resolution. I wish I could remember the name of that new codec that's coming out soon that will put even HEVC to shame (I'm fairly sure it's not h.266 VVC because they'd been using that name before I heard about this one).
You mean AV2/AV1? The successor of VP9?
when I did similar experiments in the past I didn't think the nvenc/quicksync files looked as good as software encoding.. did you visually confirm they were 'the same' ?
They looked fine to me, with the caveat that the source files didn’t contain much fast motion (which is where compression artifacts most commonly show up). Which encoder (and quality settings) to use can sometimes be dictated by what you’re trying to compress - I’d use the software encoder and a more generous RF value for an action movie, for example.
On Macs with the t2 chip, the hardware acceleration is pretty amazing
Let's say I have a lot of old gameplay footage that takes up too much space due to nonesensical high bitrates during recording. I don't use them, but want to keep them at a resonably good quality and small file size.
In that case, I assume that software encoding H256 would be the best option in handbreak? Or am I wrong?
It doesen't matetr how long it takes or how slow the encoding is, priority are a small file size while keeping a reasonable quality that doesen't look too bad when watching those old recordings.
The iPad Pro with LumaFusion handles encoding like a boss!
Another tip, Macs with the T2 chip can also do hardware H.265 encoding (through whatever software that supports "Video Toolbox", the macOS video encode/decode API).
So this kind of reaffirms my conclusions from the last time I looked into hardware-accelerated handbrake encoding vs software encoding-a conclusion I made years ago btw. Still, I wondered if things had maybe changed since I last looked into it, but I guess we're still CPU-bound if the hope is to achieve high-quality video with small sizes over a speedy workflow. I still have this one super specific question left. Will an outdated CPU like my i7 2600 be outperformed by newer processors in areas other than speed? I know it's obvious that the new chips from Intel and AMD will be way faster at crunching the numbers, but when using the x265 software encoder in Handbrake will the output file from a modern processor be of any higher image quality, or more efficiently compressed?
When using software encoding, quality won’t change between CPUs - at that point the chips are just doing the math that Handbrake tells them to. You’ll only gain performance with newer CPUs.
@@ThisDoesNotCompute you mean theoretically only the rate of time should change?
Wheres my 60 FPS Compute videos?
I need that red t-shirt!!!
So is it a bad sign if your video encoder maxes out to 100% all the time for live encoding, say with ShadowPlay or ReLive for instance, or does that mean it's working properly?
On Linux both video acceleration technologies are available (NVidia's NVEncode, and Intel's Quick Sync), and Hand Brake has a native Linux version that can be used. The OP's ThinkPad X1 Extreme has official Linux support (from Lenovo). Would the OP consider doing a Linux version of this video?
With my ThinkPad T480 (the Intel UHD Graphics 620 video hardware variant) running Linux Mint 20 the following video/picture acceleration profiles are available:
- VAProfileMPEG2Simple
- VAProfileMPEG2Main
- VAProfileH264Main
- VAProfileH264Main
- VAProfileH264High
- VAProfileH264High
- VAProfileJPEGBaseline
- VAProfileJPEGBaseline
- VAProfileH264ConstrainedBaseline
- VAProfileH264ConstrainedBaseline
- VAProfileVP8Version0
- VAProfileHEVCMain
- VAProfileHEVCMain10
- VAProfileVP9Profile0
- VAProfileVP9Profile2
Based on the above profiles most of the major media (pictures, and videos) that use the more modern codecs would be supported through hardware acceleration.
I always found handbrake too complicated to use.
MAC - weird with the mac in the back you didn't talk about macos- handbrake didn't used to support quicksync on macos for example. It now supports 'video toolbox' but its a blackbox. so what it uses under the covers is hidden unfortunately.
Apple VideoToolbox uses the GPU portion of T2(provided if your Mac comes with it) or M1 for encoding.
Pirates spend money on PC's too. So yeah, Intel should think about it. No matter if what it is being used for is legal or not. Money is Money. And not everyone will use it to shrink pirated videos.
H.265 is proprietary so I never used it for encoding. Lots of pc systems don't have the pro codecs. x264 is my friend.
i accelerated my hardware by throwing it out the window
it worked
CHECK IT OUT!
this future funk community-TDNC crossover is not something I expected but it's truly a welcome thing
OK one thing - why change Matroska for MP4? Seems like MP4 doesn't help make the file smaller or that Matroska should have any issues for RUclips to process
For the performance tests, you’re right, the container isn’t relevant. I switched it anyway simply because if I hadn’t, there’d undoubtedly be comments from people saying that my testing wasn’t consistent.
I love your shirt.
My only problem with Handbrake is that I cannot choose the flie size. Any tips?
Out of interest, if you increased the bit rate of the SW encoder to a similar level as the HW encoders were using, how would that affect timing?
Increasing the bitrate with no other changes in software encoding will only improve the video quality, not the encoding speed
And what about the other way, constraining the bitrate of the hardware encoders ? Is that going to reduce quality or increase processing time ?
Yes, bitrate doesn't affect the encoding speed at all, only the quality presets in the different encoders.
nice video🤩😄
I would stay away from hardware encoding outside of video acquisition. Unless you have unlimited hard drive space.
Edit: and obviously live streaming
What computer parts will.speed up encoding
Memory?
Processor?
Motherboard?
Processor 100% unless you have like 4gb of ram.
currently doing some tests with AMD VCE. My RX 580 is definitely faster than the Ryzen 5 3600, I'll need to test my GTX 1080 and RX Vega as well. got a 1.1GB file down to 160MB on software, and 485MB on the 580's VCE.
I am using h.264 NVEnc at 23.977 FPS, quality 18 and audio pass through with video crop on i7 processor with 4 cores and nvidea gtx 1060, it is processing around 100 fps, GPU at 30%, cpu at 52%.
Is there a way to improve performance?
Hey Colin it's Maywither, how's it goin?
Any thoughts about the effect of disk and memory bandwidth bottlenecks on this test?
Drive performance and RAM are largely a non-issue when it comes to video transcoding, interestingly enough. Processing power is the bottleneck by a very wide margin.
@bashful Fun question, but it makes total sense. He peaked around what, like 120-something fps in the fastest encodes? How big do you think a 120 frame video would be? Memory and storage speeds can maintain that rate all day. The x265 encodes are even slower than that, so it's even less work for the memory and SSD to keep up with.
So I'm using a GTX 960 and Intel 2400. Both generations are too old. Nvidia requires 10th gen or newer. Intel quire's quite bit newer. The fact that Linux acceleration only works from handbrake cli makes the entire thing a no-go for me. I'm looking to upgrade to a Ryzen 5 3600 to just brute force it.
I have a 200mbps plan but my ISP for some reason consistently provides me about 350mbps
Having both AMD cpu and gpu, is there any tests you would like me to run for you?
I can't even get Handbrake to launch on Windows anymore.....
You should test with the bitrate fixed
quick and dirty is quick and dirty
*looks at collection of laptops without any kind of remotely powerful graphics sadly*
remember, if you're talking AMD, APUs should perform just as well as a decently performant desktop AMD GPU with the same generation of encoder.
@@kiaas yeah, these are pre-Ryzen and therefore Intel. No luck on that one.
I use Handbrake all the time.
I have some chapters of a series in 4k that weigh 10gb each chapter. I want to convert those videos to 1080p and in the best possible quality. Could you give me your favorite Handbrake settings to see if I can reduce the size and keep it looking just as good?
Hi good night my name is ricardo don't know if u can help me out with my problem (handbrake) i have a TV series i want to converted from MKV to MP4 file d length is 43:39 d file size is 1.30GB MKV file after i converted to MP4 file i am getting 431MB is that correct thank u stay safe be safe out there
Try Adobe media encored 👍
Hey, multiply 1080 by 2... you get 2160. 4K is only two times of 1080. That's sadly a marketing lie since they used the horizontal number (3840, rounding it up gets you 4,000) instead of the vertical (2160) as we used to. We had 144p, 240p, 360p, 480p, 720p, 1080p, 1440p, but suddenly they ditched this fine system and went with the marketing schemes
2x the horizontal resolution times 2x the vertical resolution = 4x the pixels.
I stumbled across your video because I was trying to answer a similar question. However, when it comes to size issues with NVEnc, did you happen to see this thread? github.com/HandBrake/HandBrake/issues/2231 If I'm reading it correctly, it sounds like we shouldn't use the "Constant Quality" setting because 1) a particular number can mean different things to different encoders, and 2) "[Constant QP] unnecessarily wastes disk space and should be avoided!" We should probably be using the "Avg. Bitrate" setting instead. In your case, you can try to hit RUclips's recommended bitrates, support.google.com/youtube/answer/1722171?hl=en. In my completely unscientific testing, I found that I can set an average bitrate for an NVEnc encode that matches a software encode set to CQ 18 or 22 and the result is nearly matching file sizes and no difference in video output that my eyes can detect.
I just got a laptop with a new i7and rtx2070. It’s really fast
I understand this video is 3 years old and you are using old hardware even for 3 years ago, It would be cool to see an update on the numbers using current gen 14th gen Intel and 40 series GPUs.
My current system is a 13900k with a 4080 super and I've been using Handbrake to make my content for my Plex server smaller.
My Rip of Fellowship of the Ring was 113gb at 4KUHD and almost 87mb/s bitrate... Yes, this video needed to be compressed.
Software H.265 would have taken 4 hours encode! I could have watched the entire movie waiting for my encode LOL!
I ended up using NVEenc and that took 45 minutes, but It drastically reduced the filesize to an acceptable 40gb and 12MB/s bitrate. The newer hardware clearly added file size reduction..
Foot 👣 #intel review.
AMD hardware acceleration is just awful.
After a long time very recently I once again tried Handbrake to rip one of my DVD's (indeed using hardware acceleration), but this didn't work out at all, since only the first chapter (or only parts of it) were encoded. Other Chapters didn't even show up in Handbrake, something which still worked some years ago.
But some years ago I dropped Handbrake completely, when they dropped support of one of the video container formats. Now I don't use this format anyway, but I never went back to Handbrake. Since then I'm using FFmpeg (installed/updated like many other OS tools that I use via MacPorts) straight from the Terminal for pretty much any encoding job (AFAIK Handbrake and similar tools are just fancy frontends that are using FFmpeg nevertheless). Since I'm using a Mac first I tried hardware encoding via the Elgato H.264 HD dongle and it's horrible software when FFmpeg didn't support hardware encoding yet. But using FFmpeg's h264_videotoolbox Codec for hardware acceleration on a Mac (hevc_videotoolbox/h265 hardware acceleration isn't supported by my MacBook Pro from '15 which btw also will be my last Apple device since I'm getting a better servicable/repairable Linux-only Laptop next) is just so much faster, better and has a higher quality then Elgatos horrible software and hardware. But usually I convert my SD recordings from TV (recorded using a Dreambox 8000) via software encoding with libx264 and the HD recordings via the hardware accelerated h264_videotoolbox (btw. audio transcoding can also be done hardware accelerated via aac_at (at stands for audiotoolbox I guess?), but I haven't found an option for this is Handbrake's audio settings/Codecs).
also 2:51:
But I'm kinda curious if this can be solved too via the above mentioned method of using pure FFmpeg. I doubt that my machine supports this, but reading the documentation of the various Filters of FFmpeg I noticed that there are some variants of more common filters i. e. for scaling that also use hardware acceleration (via CUDA). For instance beside the already mentioned "scale" filter there's also an optional scale_npp filter (ffmpeg.org/ffmpeg-filters.html#scale_005fnpp) that seems to use NVIDIA Performance Primitives (libnpp) for doing the scaling in hardware. But there are more filters with hardware acceleration support like transpose_npp, overlay_cuda or yadif_cuda (for hardware accelerated interlacing).
will it work on windows xp
probably. ffmpeg will probably run in a potato if u really try to
Handbrake hasn't supported Windows XP since v0.99
use ffmpeg. very flexible
useing this to compress a 1 hr 24 min documentary onto a zip disk. yes 100mb. anyone have setings to match my needs in brake
100 MB for 84 minutes is going to mean you need super low bit rates. H265 will yield better video quality than H264. First of all, dial down the audio bit rate as much as possible but don't completely sacrifice it. If you are going to be playing on a modern computer then use a low bit rate mono Opus soundtrack (16 or 24 kbps), otherwise use mono 16 or 24 kbps AAC+HE if your playback device can understand AAC+HE. Failing that, you'll have to use AAC-LC mono at 32 or 48 kbps (or VERY aggressive VBR MP3) to retain any fidelity.
If picture content is mostly film/video sources, at the very least you'll need to tune for film and do an aggressive two-pass encode. Likely a two-pass ABR-VBV is what you'll need. I'd also play with more complex B-pyramids and longer runs of B frames (as much as your chosen H264 profile and level will allow -- or more if you're willing to produce a noncompliant file to save on bits).
Video dimensions will also be massively reduced. 100 MB minus a small amount for overhead and a 48 kbps audio track only leaves you about 120 kilobits per second for video. Even a 320x240 video at 24 fps needs about double your available bit budget. You can either reduce the video to postage stamp sizes or reduce the frame rate (15 fps at 320x240 will yield about 115 kbps video bit rate, plus audio).
84 minutes into 100 MB is one heck of a challenge!
Use fastflix
Hello
Use ffmpeg
Is the Mac mini your server?
Yeah, it’s kind of a miscellaneous-purpose home server.
This Does Not Compute is it Mac OS server or something else. Thinking of doing a Mac mini server myself.
Just regular macOS. If I wanted to run Linux I’d probably use an Intel NUC or some other SFF PC.
oz (ontre zesve )......numted
1 Hour later
nvidia encoder looks like trash during a lot of high transition scenes like in movies.
Those encoders are for game streaming, video decoding like youtube, and video encoding for work (3d rendering, transcoding your movies, etc)