Nothing that Microsoft has comes close to the functionality of ffmpeg. Apple, either, for that matter. Last time I checked neither OS even supported reading Matroska containers natively, and containers are pretty simple compared to codecs.
$ ffmpeg -codecs 2> /dev/null | wc -l
396
ffmpeg and libav are simply the most comprehensive collections of video codec software in existence.
I can promise nearly every implementation in ffmpeg is better than the competitors. No commercial product has the motivation to keep making improvements to their code that already works "well enough", and they don't have as good a set of working optimizations to apply to new codecs.
They can get new features out the door, though. One reason for the original fork in ffmpeg was that the very strict code review culture made it difficult to get anything in that was experimental or depended on personal taste.
Were you trying to use it from the API or the command line?
Either way, yes. Elenril and others were doing good work cleaning up the API when I last paid attention years ago, but there's a lot of surprise technical issues esp. in libavformat that it has to cover up. (Like, PTS/DTS in avi. Like operations that are instant in some file types might be real-time minutes in others.)
As for the command line, major customers tended to not ever give feedback on it, and it was maintained by Michael who tended to use the same code-review standards on the UI code as on the inside of a video encoder. This made it quite difficult to ever get anywhere. That's one of the reasons there was a fork back then.
Of course, there's deep technical problems there too - you can tell it to do all kinds of things that are actually really hard, and it will kind of half-heartedly do them then fail. Try converting a Matroska file to MP4 without re-encoding it; you'll get a weird error. That one weird error would take more than a year of developer time to fix.
Yeah, both. In fairness, the last time I tried using the API was before the libav split, and I have no doubt that the situation has improved; the command line, while almost ludicrously powerful, retains a lot of terrible habits -- silent defaults, mutually contradictory options, &c.
I have somewhere a much more prescriptive python library that sits on top of the command line API, but I think it'd be really great if there were a "strict" mode for the CLI -- no more implicits, no more silent rejiggering of options. If you don't totally account for your input and output, it's an error. Then, there could be a much more forgiving and intelligent front end to the front end that allowed for things like "-i foo.avi ./foo.mp4", making best guesses at each stage of the pipeline.
It makes them better than the competition, in that I can throw practically any video format in the world at libavformat and friends based players (like vlc or mplayer) and it just works.
It may not be "pleasurable" but it's nothing to be trifled with.
There's no question that ffmpeg set itself a very difficult problem, and largely succeeds. But it does so in a way that is brittle and (whether purposefully or simply out of lack of knowledge) learnt nothing from e.g. QuickTime or DirectShow.
The problem as I see it is that media manipulation is not really suitable for a one-size-fits-all command-line solution, and the API was slave to the command-line tools. This may have changed recently, which would be great.
