411–420 of 488 posts
The picture appears to be real, if we trust this source: https://www.computerhistory.org/tdih/january/6/
Why wouldn't it be real?
this to be exact https://news.ycombinator.com/item?id=48400935
Bellard hasn't been involved in FFmpeg for *over 20 years* at this point, and more like 23. His code was not great and reeked of sphagetti due to FFmpeg back then lacking any framework for code sharing between components and codecs. These days none of his code survives. Everything that became of FFmpeg is because of other developers. Yet he's treated as the one-and-only BDFL of FFmpeg, with any other developers build…
I have wondered if I sequentially ask people who is the smartest living person they know, and ask that person next, would it lead me toward the same small group of geniuses. If I were doing that with the best living coder I might well start with Carmack. So next I'd have to go to Bellard, and hope that his answer isn't Carmack.
Earlier quoted context omitted.
I can list a dozen or so co-workers from my time at Apple that I would choose in an instant.
Apple is heavy in such types, yes
Apple is a super late stage company, why would a clever person join them just to work under some middle manager.
Earlier quoted context omitted.
> 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 develo…
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…
Very very tangential, and at the risk of down-votes, the recent trend of X-articles (or whatever they call them) is extremely irksome. When I try to view on mobile it takes 3-4 hops to get to the article, and the articles always look hyper-optimized for engagement with low-attention-span readers, sort of like LinkedIn posts. Also there's irony in the stark contrast between this x-article and the Bellard's own website…
Unusable internet.
Earlier quoted context omitted.
> 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.
An algorithm is a sequence of steps and logic. You can create many different sequences to still get the same result.
Earlier quoted context omitted.
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,…
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'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 im…
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.