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
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.
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.
>>They are, but once you start learning about them, you realize the "black magic" part comes mostly from their mathematical nature and very little from them being "inteligent computers".
Oh humbug! The black magic comes from the vast resources Google drew to obtain perfect training datasets. Each step in the process took years to tune, demonstrating that data is indeed for those who dont have enough priors.
>>By the end of the book, the reader is at a loss.
>> sounds appealing but is frustratingly vague.
In a act that can only be described as `post-modern` the reviewer commits the same sin of `frustrating vague`ness that the ruined the original book. Indeed, I feel the need to write a similar review of the review to keep the meme alive. In my dreams I see a future where nobody knows of the book but for its frustrating vagueness.
When I was going through flight training, I thought about this a lot. I think the reason is that the places airplanes go is not random. If airplanes just went to random places in the sky at random altitudes, then indeed accidents would be rare, but everyone heads towards airports, which have particular traffic pattern altitudes for instance. I don't know the specifics of this situation, but perhaps the military pilot wanted to practice IFR near the ground and there also happened to be a VFR corridor passing through there. These non-random intents of pilots mean that airplanes get a lot closer together than you would otherwise think.
There's a known problem in the sailing world where people will set their autopilots to GPS coordinates from waypoints published in sailing magazines, and then collide with another vessel in the middle of deep ocean with no landmarks around.
UI Response time is at most 100 ms , as anything more that is very noticeable laggy.
Actual perception times are much lower than that, about 13ms . You can see the difference for yourself by looking at a 30FPS (33ms) and 60FPS (16ms) video , and the effect is much greater when you're actually providing the inputs.