Great software in term of both quality and active development, and I also have very positive experience interacting with their dev/contributors (reporting bugs etc.).
But not sure why this is on front page today, as it has been released almost a month isn't it?
I've always been a little unclear on the barriers between Handbrake and its dependencies. Does Handbrake maintain custom forks/patchsets that get applied to ffmpeg, etc.? I knew Handbrake as a GUI for ffmpeg, and in my research, I have come across one or two things that implied there was something unique about their backend that wasn't yet upstream, but ultimately not much else.
Since you're familiar with the project's development, would you mind clearing some of this ambiguity up for me? Thanks.
Note that HB uses a release (4.1) rather than git master HEAD. So, some of those patches may get rescinded with new ffmpeg releases.
Also, it's best to think of ffmpeg as having two parts: the libraries (codec, format, ...) and the API controller which sets up the processing pipeline and manages its run i.e. parsing the commnad line, registering input/output streams, and executing the required operations. The latter for ffmpeg is in fftools/. Handbrake implements its own top-level controller.
I noticed that it hadn't been submitted, perhaps because it was so close to Christmas. It's one of my favourite examples of free software in active development, and wanted to flag the update. Plus there are some pretty significant changes, like the move to ffmpeg.
This is huge: "Added support for AMD VCE and Nvidia NVENC hardware-accelerated encoders". Shouldn't that mean 5-10x increases in encoding speed for your average gaming Windows machine?
Yes, but beware that those encoders don't come close to providing the same quality at given bitrate. Unless you're in a huge hurry, you should stick to x264 which will generate a significantly better looking video at the same filesize.
NVenc has gotten a lot better over the years. Using the "slowest" preset definitely seems to give the best results
I encoded 1250GB~ of Star Trek: The Next Generation Blu Ray's to 355GB of H.265/HEVC video, and I feel the result speaks for itself https://i.imgur.com/VklppOK.jpg
FWIW. Running the file through an i7-4790 would take roughly 4 1/2 hours
NVENC on the Turing architecture (RTX2080/2070/2060) is at the highest quality setting comparable to x264 fast. During complex scenes closer to faster. Older architectures (Pascal etc) are worse.
Gold standard for H.264 quality/encode time/bitrate is still x264 medium / slow.
For H.265, the situation is much different. x265 is far from as mature as x264 and frankly the licensing is such a mess that it looks like H.265 might actually lose the war of next generation codec. Instead VP9 -> AV1 seems to be the industry’s codec of choice with adaption from Google, Twitch and Facebook. Also note Apple is back on the AV1 page.
I like messing around with ffmpeg from time to time, and while I love free formats I have say VP9 is practically unusable for me, it just takes insane amounts of encoding time. I'm unsure what hardware people are using for it, especially when it hardly multi-threads...
That's all too true. However it's important to remember that when H.264 started to get public traction (this is back in 2005, when Apple started pushing H.264 movie trailers), realtime CPU encoding was deemed impossible at that point in time. It just wasn't realistic back in 2005 to produce H.264 on a CPU, instead hardware encoders were used to accomplish the task.
Fast forward 10 years and basically every single laptop has hardware accelerated H.264 encoding through Intel's QuickSync FFHW and desktops have it through Nvidia. On top of that the software encoder (x264) is so fast that it's possible to do it in realtime on a CPU.
There is a fair chance that VP9 will see the exact same pattern here. Today CPU encoding is unfeasible, as you've noticed. However Intel is releasing VP9 encoding on their QuickSync encoder with newer CPU's and Nvidia will from my guess have it either 1 or 2 GPU generations from now. Same goes for AV1 here.
It's also interesting too think that the age of these aggressive improvements in CPU speed we've had over the past 14 years (from 2005) might come to an end, where efficiency instead comes from specialised hardware, such as fixed function hardware doing encoding on the chips, as NVENC/QuickSync does today. I don't know if realtime AV1 encoding will be feasible on a consumer grade CPU within the next 10 years, but i sure know it's hardware counterpart will be.
Hardware encoder are very good if you are not doing difficult bitrate like 1-2 Mbps for 1080P, and 2-4Mbps for 4K. And if you are doing high bitrate I strongly suggest using x264.
Of coz that is if you care about quality and retaining film grain that sort of things. Otherwise Hardware encoder from Nvidia is pretty good ( No idea about Radeon, but it seems Intel still doesn't care about encoding quality, they only care about speed. )
One huge issue with HandBrake is the very deep 8bit pipeline limitation, which is showing its age and lack of forward thinking. HandBrake is incapable of properly encoding 10bit streams. Until that is fixed, I had no choice but to find an alternative.
ffmpeg, sadly. No other UI wrapper gave me what I needed. MeGUI is nice, but requires AviSynth and extracting audio and video, for which I no longer have the patience.
A significant amount of content coming from a recording monitor for professional cameras, or in-camera itself, usually in ProRes/DNxHD form. Using an NLE for transcoding is miserable, and ffmpeg doesn’t have the most intuitive CLI syntax for people who just want quick buttons to press.
Pro-world also uses transcoders, and not everyone likes/is able to use Adobe for that.
Oh, there definitely are better tools out there, I’m just saying where the source material is coming from. Transcoding specific apps are relatively far and few between, so we end up having to use use other apps for this at times. Handbrake, ffmpeg, Apple’s Compression (is it still alive?), Adobe Media Encoder, etc. Having to use DaVinci Resolve, Premiere Pro, Medi Composer, etc to create proxies or flip between formats is overkill and time consuming.
FCPX has been going from strength to strength since the release, with a constant stream of big updates, and winning lots of hearts back from the FCPX backslash.
From my understanding, if the raw material is 8-bit, simply using 10-bit won't help with banding unless you also use some de-banding or smoothing filters together.
There is of course no official winner, but as of right now libav essentially withered and mostly died. Maybe the project will become more lively again in the future, but probably not.
Of those downstreams who ever switched to libav, most have switched back to ffmpeg, incl Debian and now Handbrake. The development of libav slowed to essentially a halt with next to no activity in their git, and their latest release was 11 months ago, while ffmpeg had two major releases (4.0, 4.1) and numerous point releases in that period.
libav, in my humble opinion, also suffered from NIH where they sometimes - with what looked to me like religious zealotry - insisted on doing stuff own their own, while ffmpeg at the same time happily merged tons of changes from libav. This gave ffmpeg, in addition to their brand recognition and associated network effects, yet another advantage.
It also didn't help that libav created a lot of bad publicity for themselves, starting with them trying to take over ffmpeg in a hostile manner initially instead of forking, or when their debian packages (maintained by a libav member IIRC) started telling users that ffmpeg is "deprecated". Or when one of their folks sent ffmpeg a "cease and desist" letter claiming copyright of the logo they had been using for quite a while, insisting ffmpeg stop using it. (That's why libav still uses the 2d zigzag logo, while ffmpeg switched to a 3d zigzag one).
Considering that mpv[1] recommends FFmpeg I would say FFmpeg won.
I say that because mpv is one of the projects that mostly use parts of FFmpeg internals and also one of the first projects to use modern futures (and deprecate older versions too).
Ubuntu 14.04 (Trusty) was shipping libav, but since 16.04 (Xenial) it went back to ship ffmpeg instead. So for Ubuntu LTS users at least, FFmpeg had "won" since at least 2016
thanks for this! I love handbrake, and am thankful for makemkv, but read Blu-ray so infrequently that I download a new makemkv each time. this is a fantastic compromise.
I was reading through the Handbrake changelog and noticed it mentioned changes to how blurays are handled on linux... So I tried to rip a bluray and it worked. Hopefully I can survive without MakeMKV now.
Does anyone have recommended settings for H.265 encoding of 1080p, which is comparable in quality to H.264? The former seems less sharp, using default HB presets.
Years ago when HandBrake started to ship without deCSS and use non-DVD sources, we were finally allowed to use it at work as a UI for ffmpeg to make mp4 files with x264. Due to lawyers, we were not allowed to use any software that bundled deCSS. No VLC for us, but that was okay with its lack of frame advancing.
But not sure why this is on front page today, as it has been released almost a month isn't it?