ffmpeg has competition. For the longest time it wasn't the best audio encoder for any codec[0], and it wasn't the fastest H.264 decoder when everyone wanted that because a closed-source codec named CoreAVC was better[1].

ffmpeg was however, always the best open-source project, basically because it had all the smart developers who were capable of collaborating on anything. Its competition either wasn't smart enough and got lost in useless architecture-astronauting[2], or were too contrarian and refused to believe their encoder quality could get better because they designed it based on artificial PSNR benchmarks instead of actually watching the output.

[0] For complicated reasons I don't fully understand myself, audio encoders don't get quality improvements by sharing code or developers the way decoders do. Basically because they use something called "psychoacoustic models" which are always designed for the specific codec instead of generalized. It might just be that noone's invented a way to do it yet.

[1] I eventually fixed this by writing a new multithreading system, but it took me ~2 years of working off summer of code grants, because this was before there was much commercial interest in it.

[2] This seems to happen whenever I see anyone try to write anything in C++. They just spend all day figuring out how to connect things to other things and never write the part that does anything?

▲ godelski 4 days ago | parent | next [-]

  > They just spend all day figuring out how to connect things to other things and never write the part that does anything?

I see a lot of people write software like this regardless of language. Like their job is to glue pieces of code together from stack overflow. Spending more time looking for the right code that kinda sorta works than it would take to write the code which will just work.

▲

astrange 3 days ago | parent [-]

At least they get there.

I was thinking about two types of people; one gets distracted and starts writing their own UI framework and standard library and never gets back to the program. The other starts writing a super-flexible plugin system for everything because they're overly concerned with developing a community to the point they don't want to actually implement anything themselves.

(In this space the first was a few different mplayer forks and the second was gstreamer.)

	▲	godelski 3 days ago \| parent [-]
		Sometimes they get there but a lot of times not too. I'm pretty sure there are a lot more types and the two you wrote aren't the copy-pasters either. Me, I try to follow the Unix philosophy[0] though I think there's plenty of exceptions to be made. Basically just write a bunch of functions and make your functions simple. Function overhead calls are usually cheap so this allows things to be very flexible. Because the biggest lesson I've learned is that the software is going to change so it is best to write with this in mind. The best laid plans of mice and men and all I guess. So write for today but don't forget about tomorrow. Then of course there are those that love abstractions, those that optimize needlessly, and many others. But I do feel the copy-pasters are the most common type these days. [0] https://en.wikipedia.org/wiki/Unix_philosophy

▲ skeaker 3 days ago | parent | prev [-]

That's a fun term for [2]. Our team always called it bikeshedding.