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?

Perhaps they finally did put down that cocktail.

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.

Handbrake applies about a dozen patches on top of the FFmpeg tree. See them at https://github.com/HandBrake/HandBrake/tree/master/contrib/f...

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

A GTX 1000 series does it in 4 minutes

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. )

Yes, it has gotten a lot better (Turings have improved the encoding block by quite a bit), it's still generating worse output than SW encoders.

Yep. Video quality may be lower and hardware encoders don't support as many features as x264/5 though.

The quality point is key here, unless there's some magic switches for NVENC that make better output.

There's a very visible quality drop when streaming with NVENC, but that's realtime.

NVidia says Turing has much higher quality encoding but I haven't seen any confirmation.

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.

Not gonna mention what the chosen alternative is? Ok...

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.

At least when I run it, I get options to select both x264 and x265 in 10 bit.

Yes, the option exists, but it is not a real 10 bit, because internally the pipeline is limited to 8 bit.

What does this mean? Once you've a decoded 10-bit raster, what's the limitation you're encountering?

What content comes in 10-bit in the first place? HDR is just becoming a thing and I'm pretty sure that's restricted to UHD Blu-rays.

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.

I'm surprised people working with professional footage don't have better tools for that but fair enough.

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.

>Apple’s Compression (is it still alive?)

Yes. Why wouldn't it be?

I haven’t been on Apple’s site in a long while (or on a Mac). Wasn’t sure how Compression and Motion were faring since FCPX came out.

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.

This is also interesting: https://offthetracksmovie.com/

(Interesting factoid: the same person spearheaded and designed all of FCP, FCPX, and Premiere)

In my experience, 10-bit also gives better results when transcoding, for instance smoother gradients and less banding.

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.

I have nothing to say but that I am pleased that such a great software is still in active development. I've just updated! Thank you very much.

Reading the changelog, one entry catch my eye: "Switched core decoding library from Libav to FFmpeg"

Do anyone know who won the fight of this fork?

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).

> religious zealotry

This describes the entirety of the libav initiative from birth to death. Good riddance.

Agreed. The maintainers were awful at leadership, and generally seemed like a bunch of venomous folks.

It's been a while that ffmpeg has effectively "won". A couple of linux distros that used to default to libav have switched back years ago.

I'm surprised it took handbrake so long.

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).

[1]: https://github.com/mpv-player/mpv#ffmpeg-vs-libav

YouTube-DL also uses FFmpeg to remux or convert data streams when needed too.

modern futures -> modern features

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

I don't know anyone "won" but I believe ffmpeg has remerged.

Hands down one of the best pieces of software I’ve ever used. Never had any problems with it, does what it says on the tin.

I like Handbrake but wish it has the functionality of MakeMKV too

You can if you’re on macOS. You can make it to where handbrake can read the Blu-ray.

http://www.macobserver.com/tmo/article/directly-rip-and-conv...

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.

Will these libraries continue to work after the 60-day mark?

I’m unsure. I have a paid license for MakeMKV and it hasn’t been an issue for me.

MakeMKV first, then Handbrake after.

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.

Couldn't you have forked it, removed the deCSS code and used that internally? It's opensource after all, same with VLC.

Great software. Just wish I didn't need it so often.

I loved handbrake but haven't used it in a long time since I haven't bought a DVD/blu ray in a long time.

Not that I would do this, but I've heard that sometimes people rent DVDs/BDs from public libraries and then rip them..

Yeah, but who would do that? There's no such thing as a pirate; those are stories to scare little children and media company executives.

Lovely piece of software.