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

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

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

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

not really. they're mostly pure assembly and sandboxing assembly isn't really a things

yes it is. all modern operating systems sandbox assembly. that's how it works.

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

but not these cases

It really should be, though: https://en.wikipedia.org/wiki/FORCEDENTRY

I don't see why not. What makes you think this is unique?

WUFFS 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

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

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

> I'm not sure what these two lines mean or if we can compare them, any help?

AV2 saves 25% bandwidth at the cost of 5x more decoding complexity.

What does "complexity" mean here? Computation required?

Yes, much higher computation required to encode it, and decode it, both.

He only mentioned decode complexity. Would be interesting to know the average encode complexity compared to AV1.

Encoding speed even on Mac Studio is atrocious, it’s in range of single frames per second as opposed to realtime+ for even h265

The specification for AV2 has only been finalised very recently, so performant encoders have not yet been developed. Meaningful comparison to older codecs like H265 and AV1 will only be possible once that has changed. (It'll be slower, but almost certainly not one-frame-per-second slow.)

Getting the full bitrate gains will be slower.

For any specific bitrate and quality target, there's a good chance it'll be faster.

dav1d is the av1 decoder and it’s an insane feat of engineering. Written in assembly, it even eschews the normal c calling convention to get even better performance.

The normal C calling convention is really only for cross-binary calls (e.g. between shared libraries). If you're not doing that you can ignore it; it's not a weird thing to do. It would be odd to strictly follow it in assembly and I assume compilers don't either.

Unfortunately, in absence of inlining, compilers mostly respect calling convention even when they don't have to.

Yes

It was difficult to find a nice name, with av2 :(

It works in French d2vid (Deuvid)

Also in French, different similarity, av2il hav2e

Slightly worse in English, av2age mav2ick

So you can scrobble and it gets you new music? But so, how can you listen to that new music?

You scrobble to record your listens, and then based on your listening history, there are many ways (in scrobblers and services that integrate with them) to get recommendations. Example: https://resources.onestowatch.com/how-lastfm-recommends-new-...

Rocksky itself isn't a streaming service, it tracks what you listen to from other apps/services and builds discovery/social features arround that listening history.

No, since the format is not final.

The bitstream could be "final" without the coding tools being so.

You seem to be unfamiliar with the concepts of alpha and beta or other pre-release software. Seems a strange thing to be unfamiliar though in 2026

If you see the state of what is called "production quality" software these days, alpha/beta quality has lost most of its meaning. You now just wait for "next prod"

// I jest... but only to hide the sadness

No, they're pointing out how the logic they're replying to is flawed.

If there can be a decoder, there can be an encoder.

it's a decoder of the current draft

This is amazing. I started doing the same, but I did not have the time to polish it.

Questions: why no X? Do you have a feature to resize (summarize?) to the text to fit into short boxes?

Maybe because of the API access issues? I built almost the same system as OP, but I had to drive a browser to post to X because the API was too expensive for a single person to afford. A few weeks ago they switched it so it's pennies a post now and I could finally integrate the API.

Kyber | Low-level Developers and Sales | Paris area (hybrid) and Remote in Europe | Full-time | kyber.media

Kyber is an open-source SDK and platform to control remote machines, from Remote Desktop to Robots Teleoperation/Teleobservation.

Kyber is a multi-stream and multi-actuator transport in extremely-low latency, over Quic; it encloses the server, the client and the protocol.

One could use Kyber to control robots, drones, desktop, servers in the cloud or just remote rendering of interactive 3D programs. Kyber is done for Remote RealTime, where every millisecond matters.

Kyber is developed by engineers from the VLC and FFmpeg community, and we code in Rust, in C and in assembly. We have some development in Go too.

We're a quite technical team, but cool to work with.

Contact: jobs -- at -- kyber.media (subject: “HN job”)

Kyber | Low-level Developers | Paris area (hybrid) and Remote in Europe | Full-time | kyber.media

Kyber is an open-source SDK and platform to control remote machines, from Remote Desktop to Robots Teleoperation/Teleobservation.

Kyber is a multi-stream and multi-actuator transport in extremely-low latency, over Quic; it encloses the server, the client and the protocol.

One could use Kyber to control robots, drones, desktop, servers in the cloud or just remote rendering of interactive 3D programs. Kyber is done for Remote RealTime, where every millisecond matters.

Kyber is developed by engineers from the VLC and FFmpeg community, and we code in Rust, in C and in assembly. We have some development in Go too.

We're a quite technical team, but cool to work with.

Contact: jobs -- at -- kyber.media (subject: “HN job”)

Mighty cool that you are from Europe! Good luck finding someone!

How so?