Handbrake offers you literally a GUI over ffmpeg. And sane defaults, setting ffmpeg gets overwhelming fast.

And also some nice queue management, a bit better than what you'd get from shell scripting.

The downside is that it's a GUI.

Re: GUI 'downside' - They mention a 'JSON API' to interact with libhb, though I have yet to find it in the docs.

A cli is available as a separate app

Handbrake uses ffmpeg behind the scenes and adds a nice GUI and many DVD related features. Ffmpeg is a dark art to many.

The JSON API to interact with libhb also sounds interesting.

I learned the ffmpeg cli commands by reading the handbrake logs. Rather than read tons of man pages I used HB to dial in my settings than used those settings in a pipe and tuned it further. It cut development time down by days.

I've used to work with a team that used HandBrake for transcoding - from what one of the developers told me HandBrake handles weird video formats better. Some of the videos would have troubles with ffmpeg which would produce "broken" transcoded videos, videos without audio and some other issues that I don't remember now.

Myself personally, I feel quite comfortable with ffmpeg and I never had any problems with it so whenever I can I use it.

The issues you bring up are not deficiencies with ffmpeg, but rather the user. One can prevent all of the issues you cited with the correct ffmpeg commands and an understanding of how media codecs and containers work.

An issue that causes the user to misuse the software can rightfully be considered a bug.

If a user types 3 + 4 [Enter] into a desktop calculator and gets 8, they probably would think the calculator is defective. If the calculator's manual documents that the 4 and 5 key had to be swapped for a legacy manufacturing reason, then who is at fault, the calculator or the user?

Confusing flags and poor defaults that cause the user [1] to misuse the software are "bugs" too, regardless of whether the author intended it to work that way.

[1] We're talking about the collective user here, a UI will never be intuitive to 100% of your users, but if only 5% of your users understand it that's a problem.

I don't disagree with your opening sentence, but your premise is likely based on an incomplete understanding.

The FFmpeg project produces libraries for handling digital multimedia, and it also offers a command line application. Handbrake, on the other hand, is a GUI-based application meant for DVD ripping and video transcoding. These two projects may appear to share many goals, but there is little end-user overlap and they serve quite different purposes. And I might add -- both projects are _outstanding_.

Handbrake has a specific set of tasks on which it focuses. FFmpeg, on the other hand, endeavors to provide a powerful set of multimedia codecs, container handling libraries, codec- and bitstream-level filters, a high-performance scaler, etc.

In other words, FFmpeg's command line application is meant to be used by power users who know exactly what they are trying to do and what they need done to their files to produce that outcome. Handbrake, despite its extensive feature set, simply does not expose the low-level functionality that FFmpeg/libav does. Under the hood, a lot is going on in Handbrake about which the user is totally unaware.

To take an example from the OP -- in order to avoid faulty initiation of an audio track in a video, an FFmpeg user must explicitly rebuild the output container's time base. If the team is not knowledgeable in these lower-level areas of digital media, then it seems totally logical for them to use Handbrake. Handbrake will auto-detect the need to do this process for each individual source and implement it without even informing the user in its log output.

The FFmpeg project is not responsible for teaching software developers about the fundamentals of digital multimedia, and it is not a 'bug' that they don't do so.

I'm sure that correct ffmpeg commands for various containers would prevent issues, however HandBrake does that out of the box for all the formats that company was using with one command. I don't know specific details, however I do know that ffmpeg was used for quite some time before team decided to switch to HandBrake after running tests on thousands of normal and problematic files.

If you are comfortable with ffmpeg and shell scripting you probably don't need Handbrake. It's basically a nice UI.

ffmpeg has no support for dvd titles or chapters.

- it supports extracting titles from dvd and blu ray

- a gui

How good is the ffmpeg AAC encoder these days? Ages ago when I started using HandBrake, it using Apple's CoreAudio codec on Macs for the AAC encoding was a big plus on the audio side.

It's actually fine for most use-cases. Beats FAAC and VO_AACENC easily and it's slightly worse than FDK-AAC from Fraunhofer.

In short - just fine to use and it's the default (without -strict) now.

Apple's AAC encoder is still the best out there for high bitrates.

libfdk_aac is fast and good

Which is not the default ffmpeg encoder, and due to licensing you can't distribute libfdk_aac and x264 in the same ffmpeg binary.

There's a built-in ffmpeg AAC encoder too, but despite the author's claims it is not as good as libfdk_aac.

And libfdk_aac itself isn't as good as Apple's AAC codec either. There's a Hydrogenaudio listening test demonstrating that.

Unfortunately it's proprietary, because of unclear license terms about distribution of source code and modifications (saying that you cannot charge a "copyright license fee") and it clearly says that patentable ideas in the source code are not licensed.

If you don't run ffmpeg all the time, this makes it easy. Pop in a DVD click a few buttons, and it's ready for your iPad. Try it!

Ease of use and easy installation on windows.