Hacker News new | ask | show | jobs
by baobabKoodaa 6 days ago
> ffmpeg (codec specs)

if your mental model is that somebody writes codec specs and then fabrice bellard comes in and turns the specs into C, you are dead wrong. first of all, codecs are usually reverse-engineered, there is no spec. second of all, even when a well specified document describes the codec, that spec does not describe how to efficiently encode or decode with that codec. people like fabrice bellard develop the algorithms that do that.

2 comments

The way to criticize that comment is to point out that all the major and most important codecs that are most commonly used with ffmpeg, do not come from the ffmpeg project. H.264, H.265, libmp3lame, speex, libfdkaac, etc. all come from other projects. What ffmpeg does is provide libraries for transforming decoded data between formats and calling to and from encoders and decoders and multiplexers and bitstream formats.

It may also be worth pointing out, in terms of apportioning credit fairly, that ffmpeg has not been Bellard's project since 2004. The thing we see today is no more his project than GCC or Emacs are Stallman's projects.

FFmpeg has its own native H.264, HEVC, MP3, Speex and AAC decoders. It's true that they don't have an H.264 or HEVC _encoder_ without calling out to external libraries, but they have a pretty good AAC encoder now, and TBH most use of FFmpeg is for decoding, not encoding.
> most use of FFmpeg is for decoding, not encoding.

Isn't that merely an observation of how lopsided media consumption vs production is on average?

Vocabulary please. A "codec" is software that CODes and DECodes multimedia content, while specs describe an encoded file or stream format (occasionally involving network protocols and other concerns).

In a normal standard development process experimental codecs come first, then those that have proved to work well, including having good enough performance, are described in the spec; after standardization there's very little room to "develop the algorithms" because nonconformant implementations would be useless.

Reverse engineering is limited to the abnormal case of having access to some codec but not to the standard that describes it.

> after standardization there's very little room to "develop the algorithms" because nonconformant implementations would be useless.

there is A LOT OF ROOM to develop the algorithms. it seems that you are confused about what an algorithm is, since you seemingly think that there can be only 1 algorithm that can decode a given media file.

There is a lot of room to do exactly the same thing more efficiently, which doesn't count as different algorithms.
Are bubble sort and quick sort the same algorithm?
Go take an algorithms 101 class. That's literally all it is: learning how to write different algorithms to do the same thing more efficiently.
But they COULD be entirely different algorithms. And frankly, even if they're only 20% different, that's still different.

An algorithm is a sequence of steps and logic. You can create many different sequences to still get the same result.