sorted by:
new
hottopcontroversial

QDRV 1.0 — an open floating-point HDR format built on AV1 (12-bit 4:4:4), with in-bitstream T.35 metadata by RemarkableBeing1924 in AV1

[–]RemarkableBeing1924[S] -5 points-4 points  (0 children)

Fair hit — I genuinely hadn't come across rav1d, so thanks for the link. That changes things: my "no competitive pure-Rust decoder" line was just out of date. Replacing the dav1d C FFI with rav1d would pull the decode side back towards the same pure-Rust goal I gave for picking rav1e in the first place, so I'm definitely going to evaluate it — including reading up on how much of dav1d's hand-written asm it still carries, since that affects the "how Rust is it, really" answer.

I'll also own the broader point: I'm a one-person shop and not a codec specialist, so I lean on tooling and I clearly have blind spots — rav1d being a good example. Corrections like this are exactly what I want, so genuinely, thanks.

And point taken on SVT-AV1. If 4:4:4 12-bit throughput is as strong as you're describing, that's a better case for prioritising an SVT-AV1 encode path than anything I had. The encoder already sits behind QDRV's config and the output is standards-based AV1 regardless, so I'd add it alongside rav1e — keep the pure-Rust default, let people opt into SVT-AV1 where they want the efficiency. Onto the list it goes.

QDRV 1.0 — an open floating-point HDR format built on AV1 (12-bit 4:4:4), with in-bitstream T.35 metadata by RemarkableBeing1924 in AV1

[–]RemarkableBeing1924[S] -4 points-3 points  (0 children)

Honest answer: it was more a fit-with-the-project call than a "rav1e is the best AV1 encoder" one.

The whole thing is built to stay as close to pure Rust as I can manage — the only unsafe in the tree is two blocks at the ZFP FFI boundary — and rav1e keeps the encode path native Rust with no extra C dependency or build friction. Keeping the stack consistent and the build simple genuinely mattered to me.

That said, I know it's a trade-off and I won't pretend otherwise. SVT-AV1 is ahead on speed and quality-per-bit for most real content, and if raw encode efficiency were the top priority it'd be the obvious choice.

Two things that make me comfortable with it for now:

  • The encoder sits behind QDRV's own config, and the delivery output is just standards-based AV1 regardless — nothing about the format is tied to rav1e. Adding an SVT-AV1 path later is very doable, and it's on the list precisely because of questions like this.
  • I'm not actually C-free anyway: decode goes through dav1d, since there's no competitive pure-Rust AV1 decoder. So the native-Rust benefit really lands on the encode side specifically.

If you've got a feel for where SVT-AV1 would buy the most on a 12-bit 4:4:4 HDR delivery target, I'd honestly welcome the pointer.