Thousands of special-purpose, minimally-featured, embedded systems. You don't notice them because they are invisible, and they are invisible because they "just work". For high-enough volume products they have a decoder chip or section of a gate array, but most are low-volume and can barely afford the ROM for the code.
It has to be C because so many embedded-system vendors are pathologically hostile to anything else. Most tolerate C only to try to win ports from other, typically end-of-lifed, targets, and resent it.
A few have begun to embrace LLVM, and so don't care about the front-end language -- they still only say they support C, but turn out to not notice if you feed in IR from something else. Then it becomes a question of how badly your code needs the language runtime support code, or how good you are at porting it, because they will not pick up maintaining any of that under any circumstance. GC? Ha.
Comments
Is this written in Rust? If so, did any particular Rust features help a lot in this achievement, in comparison to writing the code in C or C++?
You're thinking of rav1e, which bills itself as "The fastest and safest AV1 encoder"
https://github.com/xiph/rav1e
Being a decoder, they probably place a high priority on having the widest possible platform support. C is still top dog in that respect.
I'm curious, what kind of platforms do you have in mind, that
a) can be targeted by C, but not by Rust
b) provide enough performance to make porting a next-gen video decoder a worthwhile exercise?
Thousands of special-purpose, minimally-featured, embedded systems. You don't notice them because they are invisible, and they are invisible because they "just work". For high-enough volume products they have a decoder chip or section of a gate array, but most are low-volume and can barely afford the ROM for the code.
No, it is written in C and assembly. See the gitlab graphs:
https://code.videolan.org/videolan/dav1d/graphs/master/chart...
It has to be C because so many embedded-system vendors are pathologically hostile to anything else. Most tolerate C only to try to win ports from other, typically end-of-lifed, targets, and resent it.
A few have begun to embrace LLVM, and so don't care about the front-end language -- they still only say they support C, but turn out to not notice if you feed in IR from something else. Then it becomes a question of how badly your code needs the language runtime support code, or how good you are at porting it, because they will not pick up maintaining any of that under any circumstance. GC? Ha.
They would have had a simpler time of cpu feature detection in Rust, as it is built in. But that isn't a huge thing.