NInick__m·May 31, 2026
It's a Rust/ASM port, look there: 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.
In Dav2dmemorysafety
rav1d
Assembly2024–2026
memorysafety / rav1d
rav1d
An AV1 decoder in Rust.
8Distinct people
12Mentions
0Explicit recommenders
652GitHub stars
What to know before exploring
What it is
An AV1 decoder in Rust.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month12 dated mentions
Observed mentions: 2024-09-03 23:39:16 UTC to 2026-05-31 20:29:53 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Sep 2024 | 2024-09-01 00:00:00 UTC | 2024-10-01 00:00:00 UTC | 1 | 0 | 1 |
| Oct 2024 | 2024-10-01 00:00:00 UTC | 2024-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2024 | 2024-11-01 00:00:00 UTC | 2024-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2024 | 2024-12-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2025 | 2025-01-01 00:00:00 UTC | 2025-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2025 | 2025-02-01 00:00:00 UTC | 2025-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2025 | 2025-03-01 00:00:00 UTC | 2025-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2025 | 2025-04-01 00:00:00 UTC | 2025-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2025 | 2025-05-01 00:00:00 UTC | 2025-06-01 00:00:00 UTC | 4 | 0 | 4 |
| Jun 2025 | 2025-06-01 00:00:00 UTC | 2025-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2025 | 2025-07-01 00:00:00 UTC | 2025-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2025 | 2025-08-01 00:00:00 UTC | 2025-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2025 | 2025-09-01 00:00:00 UTC | 2025-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2025 | 2025-10-01 00:00:00 UTC | 2025-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2025 | 2025-11-01 00:00:00 UTC | 2025-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2025 | 2025-12-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| Jan 2026 | 2026-01-01 00:00:00 UTC | 2026-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2026 | 2026-02-01 00:00:00 UTC | 2026-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2026 | 2026-03-01 00:00:00 UTC | 2026-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2026 | 2026-04-01 00:00:00 UTC | 2026-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2026 | 2026-05-01 00:00:00 UTC | 2026-06-01 00:00:00 UTC | 5 | 0 | 5 |
What Hacker News says
12 sourcesI 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/dat...
There is a project to write an AV1 decoder in Rust: Rav1d (really stretching the name here).
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/
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 lik
Read the rest
ely 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.
yes 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
it's not much slower than the original C/ASM implementation (last i checked ~5%?) but that matters here
In Dav2dhttps://github.com/memorysafety/rav1d got funded and developed. it is unfortunately a bit slower (typically by a single-digit percentage) than dav1d.
In Dav2dfor dav1d there is https://github.com/memorysafety/rav1d although it reuses the dav1d assembly and performance is typically slower by a single-digit percentage.
In Dav2dFYI to non-Rust devs wondering what's going on with this code: Those two abstractions (FFISafe and WithOffset) are not standard Rust abstractions. They're something the author is building within their own library: https://github.com/memorysafety/rav1d/blob/25e5574/src/ffi_s...
So for all of the complaining about Rust abstractions and syntax in this thread, keep in mind that these particular abstractions that caused this problem are not standard. If you just want to call an extern "C" function you can do so directly in an unsafe block. The article should be read as the author debugging their Rust wrapper types, not as a generic article about calling C functions from Rust.
In Why is calling my asm function from Rust slower than calling it from C?> if called from the non-abstract horror of a language C, and the (partial) fix for that is really ugly looking low-level Rust crap that that took a _long_ time to figure out and is the exact opposite of an abstraction,
In case it's not clear, the FFISafe abstraction is not a Rust standard library feature. It's a wrapper type that the author created within their library to bypass some compiler warnings:
https://github.com/memorysafety/rav1d/blob/25e5574/src/ffi_s...
If you want to call C functions from Rust it's as simple as writing an extern block and then calling the function, though you'll have to put the call in an unsafe block because obviously the Rust compiler can't make safety guarantees across that boundary.
The Rust docs for extern are concise: https://doc.rust-lang.org/std/keyword.extern.html
In Why is calling my asm function from Rust slower than calling it from C?One of the dav1d team shared a benchmark on twitter suggesting that single core rav1d was about 6% slower than dav1d but multicore was 35% slower.
https://nitter.net/rbultje/status/1924136075426951200
But the rav1d project has 8 core benchmarks on their GitHub suggesting more like 8-10% slower on arm.
https://github.com/memorysafety/rav1d/issues/1294
In Improving performance of original dav1d video decoderSomeone asked about benchmarks, so I ran these just now to bring data to the discussion:
nathan@arm1:~/git/rav1d.new/target$ hyperfine --warmup 2 "release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8"
Benchmark 1: release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8
Time (mean ± σ): 31.532 s ± 1.971 s [User: 244.512 s, System: 1.644 s]
Range (min … max): 28.498 s … 34.270 s 10 runs
nathan@arm1:~/git/dav1d.new/build$ hyperfine --warmup 2 "tools/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8"
Benchmark 1: tools/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8
Time (mean ± σ): 29.696 s ± 2.308 s [User: 230.507 s, System: 1.479 s]
Range (min … max): 26.618 s … 35.105
Read the rest
s 10 runs
It shows that as of this moment rav1d is (31.532 - 29.696)/29.696 * 100 = 6.2% slower to decode this Netflix test sequence. Note, this is an improvement from the (32.775 - 29.696)/29.696 * 100 = 10.4% when Prossimo posted a bounty for improving rav1d [1]:
nathan@arm1:~/git/rav1d.old/target$ hyperfine --warmup 2 "release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8"
Benchmark 1: release/dav1d -q -i ~/Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o /dev/null --threads 8
Time (mean ± σ): 32.775 s ± 2.694 s [User: 254.120 s, System: 1.659 s]
Range (min … max): 28.847 s … 37.606 s 10 runs
None of this is particularly new, I reported this gap in performance over a year ago [2]. Here are some questions for HN:
Even if rav1d closes the gap, who will ship rav1d over dav1d? More than 85% of dav1d is hand written assembly that rav1d takes as-is and calls via unsafe blocks. Is this really memory safety?
The dav1d improvements must continuously be backported to rav1d, see the 82 closed PR's here [3]. Who is going to pay for this maintenance in perpetuity?
VideoLAN fuzzes dav1d and fixes bugs extremely quickly, typically less than 24h. The rav1d developers are Rust experts, but not codec experts. Is it reasonable to expect the same support?
[1] https://www.memorysafety.org/blog/rav1d-perf-bounty/
[2] https://github.com/memorysafety/rav1d/issues/804
[3] https://github.com/memorysafety/rav1d/pulls?q=backport+is%3A...
Rust allows for manual struct layout with #[repr(C)] (with some limits, but rav1d uses it heavily - https://github.com/search?q=repo%3Amemorysafety%2Frav1d%20%2...), so some of this could likely be ported over to rav1d as well. I believe there's an occasional re-sync with the dav1d code, so it's entirely possible this ends up making both projects faster.
You can see the struct the author of this PR modified here: https://github.com/memorysafety/rav1d/blob/main/include/dav1...
Interesting tool linked by the author: https://linux.die.net/man/1/pahole
In Improving performance of original dav1d video decoderI generally trust rbultje to benchmark correctly but the ravid tracking ticket has multithread numbers across multiple platforms that don't show that big a difference.
https://github.com/memorysafety/rav1d/issues/1294
Is that explained in replies? I only see the original tweet as I'm not logged in.
In Improving performance of rav1d video decoderImmunant | Software Engineer | REMOTE | Full-time | https://www.immunant.com
We're a small team dedicated to elimination of memory safety errors. We're maintaining the C2Rust tools and use it to move C code to Rust. See https://github.com/memorysafety/rav1d for an example of our recent work. Check out our github for (https://github.com/immunant) for other examples of the types of work we do.
If you're good at systems programming, we'd like to hear from you. Specifically, we're interested with folks who have significant experience in one or more of these technical areas:
- C/C++ and/or Rust (familiarity with assembly language is a plus)
- Compilers for any of the above languages (LLVM experience is a plus)
- Operating systems, hypervisors, firmware, bootloaders, JITs.
- Build systems commonly used in the above technical areas.
Folks with s
Read the rest
uperficial knowledge in one of these areas are not encouraged to apply. If you have experience managing software developers in addition to meeting the technical requirements, you are encouraged to reach out. Please note that we can only consider candidates resident in the US.
We offer a remote-friendly, highly collaborative work environment with high flexibility and competitive benefits.
Send your resume to team@immunant.com; we look forward to meeting you.