5 ms·
Sorry if this sounds naive, but does it make sense to write a codec library in C/ASM considering how well Rust is progressing, especially when, as the author pu
by poly2it 4mo ago
Sorry if this sounds naive, but does it make sense to write a codec library in C/ASM considering how well Rust is progressing, especially when, as the author puts it, AV2 decoding is roughly five times more complex than AV1 decoding?
- jbk 4mo agoBecause it's 5 times more complex, you need to get the maximum performance available. Therefore more ASM than ever. Rust does not bring more performance. Just more safety.
- LoganDark 4mo agoThe safety can be worth it in certain cases. Like when handling untrusted input. And it's not just Rust: look at WUFFS for example. WUFFS can actually rival handwritten implementations in certain cases.
- throawayonthe 4mo agobut not these cases
- IshKebab 4mo agoI don't see why not. What makes you think this is unique?
- adgjlsfhk1 4mo agoWUFFS like approaches work better for algorithms like lz77 that are substantially bandwidth constrained. for something like a video codec, the computational intensity is much higher so you need better codegen to reach max speed
- bigyabai 4mo agoIt really should be, though: https://en.wikipedia.org/wiki/FORCEDENTRY https://en.wikipedia.org/wiki/FORCEDENTRY
- xp84 4mo agoAre video codecs in the present day able to be sandboxed? In my fantasies at least I’d like the worst a malicious video file can do is cause garbage output or cause the codec to crash. Forgive the ignorance, I have worked entirely in the abstracted layers of the stack, and mostly web.
- adgjlsfhk1 4mo agonot really. they're mostly pure assembly and sandboxing assembly isn't really a things
- nullpoint420 4mo agoyes it is. all modern operating systems sandbox assembly. that's how it works.
- LoganDark 4mo agoWindows may use virtualization-based security by default, but I'm not aware of macOS or Linux doing the same -- Apple builds security directly into the silicon such that no virtualization is required, and Linux just rawdogs everything. Whether that counts is up to you. I suppose it's still "sandboxed" in that it runs in a less privileged context than the kernel.
- cesarb 4mo ago> Rust does not bring more performance. Just more safety. Though more safety can in some cases bring a bit more performance. For instance, with Rust you can often avoid "defensive copies" of objects.
- itishappy 4mo agoWhen writing a high performance video codec avoiding defensive copies of objects is something you want always, not just often. C makes it easy to be fast but hard to be safe. Rust makes it easy to be safe but hard to be fast. Also note that video codecs tend to wrap C or Rust around handcrafted ASM. Performance is king.
- alkonaut 4mo agoIt brings tooling that is a LOT easier. Just things like dependency management, test running and so on is so much better in Rust than in C, even if you happen to write the exact same code because you basically write unsafe code and hand rolled assembly for many things. I think this is people using the tool they know rather than the best tool (And if you know a tool well, it might become the best tool for the job because of that). It could be because a huge chunk of existing code can be re-used. But all else being equal (existing code, existing developers don't exist) I refuse to believe a codec should ever be written in C ever again.
- Telaneo 4mo agoGo ask FFmpeg what they're writing their encoders and decoders in.
- latexr 4mo agoThat isn’t particularly helpful to someone asking a question in good faith. What others are using doesn’t clarify why they are using it. Plus, FFmpeg is itself a decade older than Rust. The OP is asking about starting a new project today.
- Telaneo 4mo ago> What others are using doesn’t clarify why they are using it. It does if you ask them, or at least research the topic at hand.
- latexr 4mo agoIsn’t that just the same as answering “Google it”, then? We’re on a discussion forum, where matter experts visit, talking about a specific topic. If one can’t ask their questions in this highly relevant situation, where can they? The point of HN is supposed to be gratifying curiosity.
- Gigachad 4mo agoJust don't try reporting a security issue to them.
- Telaneo 4mo agoIs this a reference to this: https://news.ycombinator.com/item?id=45785291 https://news.ycombinator.com/item?id=45785291 ? If so, FFmpeg's stance is very understandable in my opinion.
- Gigachad 4mo agoSomewhat, but somewhat not. Yes it's a very obscure format, and yes it's partially a marketing stunt from Google for their AI tools. But it's also a real bug which is exploitable on ffmpeg. And we have seen in the past that state sponsored hacking groups specifically target media decoders with obscure formats that aren't often tested or known about. Media decoders are one of the highest risk programs since they deal with untrusted user input and are incredibly complex. So just because a large project like ffmpeg uses C, doesn't mean there isn't very good reason to consider a language like Rust for saftey reasons.
- MattRix 4mo agoYes? There is 5x more code to optimize the ASM for.
- Arodex 4mo agoThe algorithms deployed in these kind of codecs take into account not only human vision and mathematical laws of information, but also nitty-gritty details of how computers work, which are optimally exploited by directly having humans write detailed assembly rather than a compiler make a best guess and effort.
- alkonaut 4mo agoSurely 100% of these low level features are availale in rust too? I understand it is a massive undertaking and builds off the previous codec(s) but writing these things by hand such as inline assembly seems to be as easy if not easier in Rust? And as soon as you walk into concurrency territory for a complex codec like this then it seems almost impossible for humans to do correctly while retaining safety.
- rafaelmn 4mo agoWhy ? If it's shared reads and scoped writes (read-only look up, output to a thread owned buffer span) concurrency seems pretty straightforward. Rust can only prove a limited subset of correct programs to be safe, when you're doing bare metal stuff you've often not in that subsystem and drop down to unsafe. I'm guessing there's always stuff that's not perf critical and can live in Rust sandbox - so not saying no wins - but it doesn't sound like Rust is a no-brainer.
- alkonaut 4mo agoI mean all else being equal, I'd just take the ergonomics (dependency management, build-system/multi-targeting, modern language features, no h-files, ...) and run. I can always just write at the level I want (safe rust, unsafe rust, C, inline asm...). I still think no one should in 2026 be writing a nontrivial codec or anything parsing untrusted data, in C. There's just no excuse. The gains are re-use of skill and code. And I hope that's the reason this is continuing with C, this is basically a v2 of an existing project, not a greenfield codec, even if it's much larger.
- cogman10 4mo agoEncoder and decoder writers frequently need extremely fine grain control over SIMD instructions in order to get good performance. The way they weave these instructions can be very hard to express with a high level language. Further, there's a ton of work with arrays and importantly parts of arrays. They can, for example, need to extract every other element up to 1/2 the array. Unfortunately, rust has runtime array bounds checks which make writing that sort of code slower. The compiler can elade those checks, but usually only in simple cases. The authors would be writing a bunch of unsafe rust to get the performance they want and rust makes that more painful on purpose. I like rust, but C/ASM really is the right choice here. This is one of the few cases where rust's safety is a major detriment.
- dcsommer 4mo agoPerformance should not be priority #1. Security should be. Why do we slow down all CPUs to prevent SPECTRE attacks yet continue to write in C? As rav1d shows, the perf loss is far less to migrate from C to Rust than it is to apply SPECTRE mitigations, and adding a sandbox around a memory-unsafe codec is going to be way more expensive again than using Rust code to start.
- cogman10 4mo ago> As rav1d shows rav1d is not a full rewrite of dav1d to rust. So it really doesn't show that. It's currently C + rust + asm. I don't think we can say anything about what this does or does not prove about the performance of safe code. > Performance should not be priority #1. Security should be. Entirely depends on the application. The reason rust has `unsafe` is because there's some situations where performance needs to preempt potential security problems.
- dcsommer 4mo agoCodecs are difficult and expensive to develop. Therefore they get reused in many contexts, including security critical ones. Sandboxing is shown over and over to not be a great security solution, so what this means in practice is that security-critical software that needs software decoding get pwned because software engineers don't care to prioritize it in the first place. Why shouldn't safety be the default? If you really want to, it wouldn't be too hard to maintain a patch on top of rustc to drop the bounds checks if you want to compile object files without them. Software decoding has a safety culture problem, and we need to talk about it.
- muhbaasu 4mo agoThe ffmpeg devs have said many times in public that they routinely get speedups of 10x or more over C code. I'm not a reputable source on this myself but I highly recommend looking into their channels, mails, or posts.
- throawayonthe 4mo agoyes it makes sense to use C/ASM here, but if you're curious, there is a rust port of dav1d named rav1d: https://github.com/memorysafety/rav1d https://github.com/memorysafety/rav1d it's not much slower than the original C/ASM implementation (last i checked ~5%?) but that matters here
- stukenov 4mo ago[dead]
- Thaxll 4mo agoIt is much slower than 5%, there were other independent tests that put it around 20%.
- nick__m 4mo agoIt's a Rust/ASM port, look there: https://github.com/memorysafety/rav1d/blob/main/src/ext/x86/x86inc.asm https://github.com/memorysafety/rav1d/blob/main/src/ext/x86/... I am not sure if it is that much safer than the C version when raw assembly is still required.
- IshKebab 4mo agoI don't know why you've been down-voted. It definitely isn't an optimal decision. A video codec isn't all assembly. There's plenty of plain unsafe C code. E.g. this is the first random file I clicked. It has a ton of raw C pointer stuff just begging to be exploited. https://code.videolan.org/videolan/dav2d/-/blob/main/src/data.c?ref_type=heads https://code.videolan.org/videolan/dav2d/-/blob/main/src/dat... There is a project to write an AV1 decoder in Rust: Rav1d (really stretching the name here). https://github.com/memorysafety/rav1d https://github.com/memorysafety/rav1d They got within 5% of the performance of dav1d and held a contest to close the gap but I think I read somewhere that this wasn't achieved. https://www.memorysafety.org/blog/rav1d-perf-bounty/ https://www.memorysafety.org/blog/rav1d-perf-bounty/ They claimed > This is enough of a difference to be a problem for potential adopters, and, frankly, it just bothers us. But in my opinion nobody actually cares about 5% in absolute terms. It's likely just Rust naysayers using that as an excuse. I think the likely reason for dav2d using C is that they can reuse lots of code and infrastructure from dav1d. But I agree it would be much better if they worked on Rav2d instead (these names!). You can hardly complain about a 5% overhead if you're opting in to 5x more decoding complexity.
- stukenov 4mo ago[dead]
- skelpmargyar 4mo agoOf course any random C file is going to have pointers. Where can anything in the linked code be exploited? It seems like they're testing for bad input data with asserts to catch bugs in some functions, and properly validating bad inputs in others. Just because they're writing C doesn't mean it's vulnerable. How can you claim nobody cares about 5%? A 5% performance increase is significant. And video decoding is not always for playback, where 5% may not matter as much.
- IshKebab 4mo ago> Where can anything in the linked code be exploited? Difficult to tell - that's the point!
- nmz 4mo agohttps://youtu.be/nepKKz-MzFM&t=7195 https://youtu.be/nepKKz-MzFM&t=7195 If you can stand Lex Friedman for a bit, the VLC authors talk about why you use ASM for a video decoder instead of pure C or rust.
- stukenov 4mo ago[dead]