[Ronsenshi]

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.

[AndrewUnmuted]

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.

[KerrickStaley]

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.

[AndrewUnmuted]

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.

[Ronsenshi]

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.