Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dav2d

jbkempf.com

Post reply on HN
Print view View original

201–210 of 212 posts

Re: Dav2d

#201

Post by rbultje »

kingstnap wrote: post #59

This seems like an interesting case to test AI agents on. Like we had weird examples like C compilers and Bun. This is a much more interesting example because its highly nontrivial. AV1 exists, Dav1d exists. Lets see AI take the AV2 spec and Dav1d code and try to make a working high performance AV2 decoder.

> Lets see AI take the AV2 spec and Dav1d code and try to make a working high performance AV2 decoder.

That sounds like one of these high-risk, high-reward things that are great for people / projects / companies who have nothing to lose, but is not a great baseline strategy for an established market player. AV2 is here with support from aomedia and its members. AV2 will be used, and we need a production-grade decoder regardless of where AI is at, so it makes much more conservative business sense to use established approaches (language: c/asm, devteam: ffmpeg/dav1d) as a starting point. While that's happening, we can dabble in AI and other risky stuff and see if it helps. If so, great, and if not, nothing lost.

Re: Dav2d

#202

Post by LoganDark »

nullpoint420 wrote: post #165
adgjlsfhk1 wrote: post #142

Earlier quoted context omitted.

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.

Re: Dav2d

#203

Post by IshKebab »

skelpmargyar wrote: post #136
IshKebab wrote: post #95

Earlier quoted context omitted.

I 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 her…

Of 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 al…

> Where can anything in the linked code be exploited?

Difficult to tell - that's the point!

Re: Dav2d

#206

Post by FrostKiwi »

pantalaimon wrote: post #113

I'm not quite convinced a 25% reduction in size is worth effectively obsoleting all devices that have hardware decoders for AV1 but will struggle to decode AV2

Same comment, same wording was had when going from H.264/AVC to H.265/HEVC and again to AV1. Across the board it's 30% better Size vs Quality and with an X amount increase in compute required to encode and decode.

Each time these standards were put into ink, they were years from being practical.

Re: Dav2d

#207

Post by GaggiX »

lostmsu wrote: post #199
Dylan16807 wrote: post #191

Earlier quoted context omitted.

Almost half of the file is audio, so you're not saving as much.

Hopefully audio codecs will progress as well. I noticed that too. When I tried extreme screen recording compression with AV1 audio became a noticeable part of the bottleneck.

Is opus being used for the audio or it's not the solution for extreme lossy compression?

Re: Dav2d

#208

Post by ZeroGravitas »

account42 wrote: post #182

Is there actually a reasonably performing encoder that can compete with the x26* family in real world conditions this time?

Last time Intel's SVT-AV1 managed to beat both x265 and x265 at various quality/speed tradeoffs.

I assume there will be an SVT-AV2 too which will semi-automatically gain from the SVT foundation for working with lots of cores but will still need specific work to support and then tune AV2 encoding.

Re: Dav2d

#209

Post by alkonaut »

rafaelmn wrote: post #178
alkonaut wrote: post #171

Earlier quoted context omitted.

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

Why ? 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…

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

Re: Dav2d

#210

Post by lostmsu »

GaggiX wrote: post #207
lostmsu wrote: post #199

Earlier quoted context omitted.

Hopefully audio codecs will progress as well. I noticed that too. When I tried extreme screen recording compression with AV1 audio became a noticeable part of the bottleneck.

Is opus being used for the audio or it's not the solution for extreme lossy compression?

OPUS is the default now, but there's more room. Especially with neural codecs.
Post reply on HN