Hacker News Reader

Comment by miki123211 | Hacker News Reader

It's interesting to me that most of Bellard's work is basically turning specs into C.

His most important projects are ffmpeg (codec specs), qEmu (ISA specs), QuickJS (the EcmaScript spec), tinyC (the C spec), and his telecom company (LTE specs). I guess the pi calculations and neural network stuff are exceptions.

Just to be clear, this doesn't make his work any less impressive. Highly performant codec and emulator implementations are no easy feat; it's just interesting that most of this work falls into that relatively narrow area.

View on HN

It's worth noting that most communications specifications that involve an encoder/decoder pair communicating over a channel only specify the encoder. Standards purposely leave the decoder open to allow systems to progress as technology develops and to allow competition between implementations. This also makes a standard simpler, as a decoder is usually more complex than an encoder since it has to deal with noise and other effects introduced by the channel. Consequently, implementing a competitive standards compliant decoder involves R&D and is not a case of following a predefined path.

I've always seen Bellard as an engineer who programs rather than a pure programmer.

It is exactly the opposite for MPEG, which only specifies the decoder (i.e. how frames should be decoded).

The concept is similar, in that with MPEG it is the encoder that is the harder of the two, since it has to deal with the noise and real-world effects in the source image.

What I should have written is that the "hard" part, which is generally left unspecified, is the part that removes redundancy. An MPEG encoder removes redundancy whilst its decoder adds redundancy. An FEC/communications encoder adds redundancy whilst its decoder removes redundancy.

It's not really about difficulty (although encoding is definitely far more difficult), it's about there being multiple valid encodings.

If you have two red boxes on a black background in one frame, and a single red box in the middle on the next, UIUI there are at least two ways to encode this: "left box moved right a bit; right box disappears" and "right box mounts left a bit; let box disappears".

In a complex scene, there is a huge space of possible ways to encode a frame that give identical outputs, and even more that are lossy. Choosing one that compresses well but is visually similar (and not too slow to find) is a quality issue for the codec. It wouldn't make sense to specify the algorithm for that in the spec.

I agree. We are in danger of arguing about semantics/language, despite the effects of the words we are using being the same. I guess that's why Information Theorists use mathematics over words.

Maybe they meant encoding, the file format.

But that only specifies the decoder.

The format for all modern video codecs is not the kind of format where any specific piece of uncompressed input should always be encoded the same way, but more like a very restricted programming language that gives the encoder a lot of tools to compress the video, and which tools they use and how they use them are up to them.

I think it's neither the encoder nor the decoder that's specified but rather the encoding ie the bitstream format. At least for video streams building a competitive encoder is far more difficult than the corresponding decoder.

If you actually work with ffmpeg, it's rather quite impressive how pluggable the architecture is. The codecs have huge amount of quirks and disagreements about basics (what is a "frame" in audio, subtitle, and video worlds?) and even their environment (passing frames around software and hardware coders is way different).

That fact that you can (almost) freely mix and match processing between such different worlds is quite an achievement and libav (IMO) is decently well designed to allow that.

This description feels like how jQuery unified all the disparate JavaScript implementations behind a single framework.

> 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.

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.

That's actually how I was trained. The spec and the implementation (and the testing) were separate areas; sometimes, done by different people.

These days, I tend to mix them all together, and I think I get good results.

I strongly suspect that a lot of folks, these days, only do the middle one.

> I strongly suspect that a lot of folks, these days, only do the middle one.

Ain't no one willing to pay for all of that. The clear separation is something you only see remaining in academia and industries where code quality issues have legal consequences (i.e. aerospace, marine, automotive and medical), and even there, pressure is high to relax rules viewed as "arcane".

Writing good specifications, documentations, implementation code and tests each is an art form in itself

I’m not so sure.

I see a lot of “Ready, Fire, Aim” behavior, hereabouts, and can’t help but imagine that it extends into our basic workflows.

It’s entirely possible to create a huge ball o’ mud, that works, but is unmaintainable, and damn near impossible to adapt to changing circumstances.

I just went through that, with my LLM. Really easy to simply say “Screw it. Let’s ship.”

It doesn't seem like you're disagreeing with him?

> Ain't no one willing to pay for all of that.

That made me think that he didn't think it was possible.

I guess I'm a cynic, but I think that many companies, these days, are willing to pay -and pay a great deal-, for exactly that.

> I guess I'm a cynic, but I think that many companies, these days, are willing to pay -and pay a great deal-, for exactly that.

lol, where? Outside of the industries I mentioned (and banking/insurance, which falls under the "legal consequences" catch-all)... good luck.

Government procurement only cares about price, and you see that confirmed whenever some government "digitalization" project balloons or the balloon inevitably explodes. Large companies live and breathe on Excel and shadow IT. Small companies want something that reasonably works and can be somewhat afforded.

I dunno. I regularly use mobile and host software that crashes all the time, goes into memory panics, has terrible UI, is inscrutable, not accessible, and just damn ugly.

Almost every corporate dashboard I use -Web or app- is junk. I was watching old folks wrestling with a terribly-designed UI at a medical lab, recently. If the designers had just given a tiny, tiny little shit, those folks would have had it a lot easier, instead of having to be walked through it, by the receptionist.

I have to restart most of my streaming apps, several times a week.

The folks that wrote those, get paid plenty.

I think perhaps the missing piece here is the suggestion that the status quo is cheaper in the short term but (IIUC you're suggesting) more expensive in the long term. Of course the problem is convincing current management first of this fact followed by why that should matter to them.

But amusingly this all seems to be rapidly changing with the advent of AI agents since they don't work all that well without a clear spec and thorough documentation (and likely comprehensive tests as well).

There was a time when we would spend an enormous amount of time defining a spec, so that we can farm out the code. Now, we farm out the spec so that we can spend an enormous amount of time with the code.

Now we replace both with prompts.

Interesting observation, similar manner of work as Linus Torvalds. These guys implement existing ideas well, consistent and open, but are not inventors.

Git?

That's his point. I do not agree with it at all, though.

Linus himself phrased it as git being about applying his filesystems knowledge to source management. You can't take that statement at its face value.

Many of Bellard's projects boil down to applied tcc but just being able to understand tcc in the first place is out of the reach of most people who call themselves "programmers". And then applying it to a novel field solving problems people didn't even know they had.

That's exactly what "inventing" is.

Carmack didn't invent logarithms. But without people like him who innovated building on someone else's innovation, and on many people's common knowledge, we'd be still running away from lions in the Savannah.

Maybe pi is a spec. Just not written by man.

I don’t think the distinction is actually that interesting as you could call any piece of software a spec

But I was told “spec implementators” were prime for LLM replacement

Reply on news.ycombinator.com