alt.hn

5/31/2026 at 11:44:45 AM

Dav2d

 https://jbkempf.com/blog/2026/dav2d/

by captain_bender

5/31/2026 at 2:41:02 PM

"Too Many Requests"

- https://web.archive.org/web/20260531130034/https://jbkempf.c...

- https://archive.md/ln5UE

by celsoazevedo

5/31/2026 at 2:48:00 PM

Too much traffic from HN?

``` Too Many Requests The page you have tried to access is not available because the owner of the file you are trying to access has exceeded our short term bandwidth limits. Please try again shortly.

Details: Actioning this file would cause "jbkempf.com//blog/2026/dav2d/" to exceed the per-day file actions limit of 160000 actions, try again later ```

by kaka314

5/31/2026 at 3:52:42 PM

I don't know if I'm underestimating HN's reach but I doubt we did that, probably traffic from a much bigger aggregator/forum

by BetterThanSober

5/31/2026 at 4:17:53 PM

You are underestimating HN's reach, this happens all the time. As someone who has been on the front page of HN it's a pretty big rush in traffic!

by jezzamon

5/31/2026 at 6:04:31 PM

I'd wager that the load is amplified by other sites that treat HN as a goldmine of tasty links.

by pstuart

5/31/2026 at 6:50:54 PM

Hacker news doesn't generate much traffic, despite what people are saying.

The host here has a limit of 160000 files served each day. That is extremely low. If the site has an icon, css, a js file and a few images it's 10 files each visit. That's will limit it to 16k visits/day. If there are more files loaded it might just handle a few thousand visits, and they have received more than that from HN now.

by NorwegianDude

5/31/2026 at 7:37:52 PM

Wait really? I'm not really sure what to think and I posted before I saw this... I wonder why the limit is so low?

by ethin

5/31/2026 at 2:59:20 PM

i had that too once i used dyndns address my linux apache crashed when some one posted it here

by hideout_berlin

5/31/2026 at 12:45:41 PM

'AV2 decoding is roughly five times more complex than AV1 decoding. In practice, that means software running on today’s hardware will struggle to decode AV2 in real time without careful, architecture-specific optimization'

AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.

by jordand

5/31/2026 at 2:30:48 PM

Intel's Arc dGPUs were really compelling for dedicated AV1 encode and decode, especially the small form factor of some cards. You could even fit it as a secondary card in a PC dedicated to recording and encode workflows for OBS.

Hope we get a similar option with future lineups that support AV2, especially given how popular video creation and streaming are now.

by kmfrk

5/31/2026 at 4:04:21 PM

Is there a compelling reason encoding needs to be done locally?

The point of encoding is to reduce downstream bandwidth for the viewer, and upstream bandwidth for the distribution network.

The content creator only needs to upload it once.

by thrownthatway

5/31/2026 at 8:32:31 PM

Yes.

An uncompressed 1080p, 60fps video with 24-bit color depth would need around 3Gbps to be streamed. And even if you don't need to stream it, that would still consume a sizeable portion of the write throughput of the fastest SSDs currently available; if you go up to 4K, you'd actually exceed that by a lot (not to mention, 1tb of storage would last for about 10 minutes of video).

by esposm03

5/31/2026 at 9:03:06 PM

Using raw uncompressed bitrate is a bit disingenuous. How about comparing an older, widely supported codec like H.264 as a baseline?

by Ecco

5/31/2026 at 4:14:58 PM

Well yes? The platforms only accept certain resolution/bitrates and also most of America isnt running 1gig up. They're running 5-30 mbps up. So yeah they need to encode it.

by halJordan

5/31/2026 at 7:00:21 PM

> They're running 5-30 mbps up

Do you not have 98% high speed 5G coverage?

by thrownthatway

5/31/2026 at 4:21:39 PM

If you don't encode locally as the video is created, you either need to store RAW frames which takes enormous amount of storage, or you use a different format and suffer quality loss by transcending.

by phkahler

5/31/2026 at 4:25:39 PM

Video calls & streaming.

by IshKebab

5/31/2026 at 6:00:40 PM

this

for other cases, I can just wait more for my cpu/gpu/cloud to do the job

by sysguest

5/31/2026 at 1:22:09 PM

I came to post this as well. Until widespread, inexpensive hardware catches up to a 2018 codec, AV# will remain a niche ideal.

by mrbluecoat

5/31/2026 at 1:32:33 PM

Hardly niche. My laptop isn't new and it has hardware AV1 decoding and encoding. My 10 year old iPhone 7 can play 1080p AV1 video in software for over 200 minutes with VLC. The iPhone 7 was released in 2016, a year and a half before AV1. The dav1d decoder is mighty.

Netflix uses AV1: https://netflixtechblog.com/av1-now-powering-30-of-netflix-s...

YouTube uses AV1. It's tough to be more mainstream than that.

Right click on a YouTube video and select Stats for Nerds. If your system is capable of it, chances are it will be playing back in AV1.

Most of the YouTube videos I watch these days are AV1 encodes. Sometimes it's in VP9 and occasionally it's H.264.

by breve

5/31/2026 at 2:00:54 PM

Supported is different from doing it well though. You do notice the performance hit even on TVs that playback YouTube videos on AV1.

Even on 1080p videos running on AV1 on 1x, the TV system bogs down and any kind of interaction has a variable 1-3s lag. On some TVs if you do 1.25x the TV automatically "downgrades" the resolution to 480p to avoid dropping frames.

I wish there was an option to still use VP9 / H.264 on those systems (even limited to 1080p).

by weiliddat

5/31/2026 at 4:48:37 PM

More reason to never use the builtin stuff in a tv. Cheap sticks can handle decoding fine.

by Dylan16807

5/31/2026 at 2:50:20 PM

Youtube artificially limits the resolution, on mine if you cast the exact same video it doesn’t impose that limit and works fine.

by TingPing

5/31/2026 at 2:03:46 PM

Yeah I could imagine the AV1 codec sticking around for a very long while, even as a fallback for AV2. There's still hundreds of millions of people out there using old/cheap devices (especially in developing countries) where that battery drain from software decoding is a big problem, so AV2 would be nonviable.

by jordand

5/31/2026 at 3:11:31 PM

Some of the early use of VP9 and AV1 was Netflix serving video to people in developing countries. Their metered bandwidth was more of a bottleneck than the CPU playback.

by ZeroGravitas

5/31/2026 at 1:53:10 PM

Same. Mostly AV1, sometimes VP9, and rarely h264.

What's missing mostly: live streams which are h264.

Currently, and I say currently, dav1d is so fast, no worries on that side.

by sylware

5/31/2026 at 12:57:44 PM

> AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.

Yes, this is going to be fun to watch.

by jbk

5/31/2026 at 8:59:18 PM

What's next, Dav4d?

by arikrahman

5/31/2026 at 7:36:46 PM

Ouch, looks like the HN hug of death struck again. Gives me error 429.

by ethin

5/31/2026 at 7:00:39 PM

> The page you have tried to access is not available because the owner of the file you are trying to access has exceeded our short term bandwidth limits. Please try again shortly.

HN hug of death

by mudkipdev

5/31/2026 at 4:17:41 PM

A codec spec isn't done until there is at least one decoder developed in the field. So reference + 1. The field implementations often become the de facto spec.

Reading the MPEG1 specs back in the 90s as a child opened my eyes to how to define complex systems. For a media coding standard, they spent most of their time saying how to interpret encoded bytes, which I realized is genius. Be descriptive about decoding and you don't have to be prescriptive about encoding. Encoding is where you can apply all the creativity, but you need to provide a way to have a shared understanding of the encoded bytes.

by genxy

5/31/2026 at 7:03:28 PM

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

by pantalaimon

5/31/2026 at 7:28:47 PM

Modern video services perform multiple encodings with different codecs, bitrates and screen dimensions, and serve up the most appropriate format that the client device can decode. Youtube has hundreds of format variants:

https://gist.github.com/MartinEesmaa/2f4b261cb90a47e9c41ba11...

Devices with AV1 hardware decoding - rare as they are - won't be obsoleted for a long time.

by amiga386

5/31/2026 at 1:13:02 PM

I thought this was about Dave2D

by anoncow

5/31/2026 at 4:22:01 PM

Yeah I suppose it’s named after dav1d but still seems like a pretty unfortunate name collision.

by ltheanine

5/31/2026 at 4:57:02 PM

same

by fitzroymckay

5/31/2026 at 5:49:18 PM

Exactly

by xk9

5/31/2026 at 2:11:26 PM

Same

by adithyassekhar

5/31/2026 at 2:31:21 PM

Seems like the blog succumbed to the HN hug of death (`Actioning this file would cause "jbkempf.com//blog/2026/dav2d/" to exceed the per-day file actions limit of 160000 actions, try again later`), is there a copy available somewhere?

by plopilop

5/31/2026 at 12:44:32 PM 

  ... improvements around 25% compared to AV1

  AV2 decoding is roughly five times more complex than AV1 decoding
I'm not sure what these two lines mean or if we can compare them, any help?

by Slurpee99

5/31/2026 at 12:57:34 PM

I understood it as compression is 25% better : a quality of 10mbps in av1 can be achieved with 8mbps in Av2. But, it needs 5 times more compute power for this 25% gain.

by whynotmaybe

5/31/2026 at 12:56:11 PM

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

by jbk

5/31/2026 at 1:38:09 PM

What does "complexity" mean here? Computation required?

by 0x1ceb00da

5/31/2026 at 2:07:55 PM

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

by BillStrong

5/31/2026 at 3:21:39 PM

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

by Caspy7

5/31/2026 at 7:16:19 PM

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

by kiicia

5/31/2026 at 8:07:52 PM

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

by F3nd0

5/31/2026 at 3:53:32 PM

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.

by WD-42

5/31/2026 at 4:29:20 PM

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.

by IshKebab

5/31/2026 at 1:50:27 PM

Yes

by simjnd

5/31/2026 at 12:50:49 PM

Smaller files but harder to decode

by croes

5/31/2026 at 1:28:39 PM

> Make it fast on older desktop, by writing asm for SSSE3+ chips

I guess 5 years ago (around the time when Intel stopped making SSE-only chips) is technically "older", but I wouldn't prioritize avx2 when devices intended for consuming media definitely experience much less pressure to upgrade than workstations…

by remix2000

5/31/2026 at 2:46:53 PM

Almost every Intel CPU released since 2013 has AVX2 support. Some Atom SKUs were longer holdouts, but the fraction of x86 CPUs shipped in the last decade that have AVX2 support is very high.

by otherjason

5/31/2026 at 12:49:30 PM

I would love to see comparisons with AV1 on very low bitrates.

by GaggiX

5/31/2026 at 12:52:12 PM

Return of the 8MB Shrek encodes?

by UnlockedSecrets

5/31/2026 at 1:26:21 PM

https://web.archive.org/web/20210416200451/https://cdn.disco...

Shrek 1 at 8.34MB including audio.. insane

by MaxikCZ

5/31/2026 at 2:09:29 PM

Video resolution: 128x72, hahah. Late 90s RealPlayer postage stamp video is back! To its credit, that whole movie is probably smaller than RealPlayer itself was.

by coldpie

5/31/2026 at 2:09:39 PM

I love this, hope to see a AV2 version at 8MB

by GaggiX

5/31/2026 at 2:01:45 PM

6MB should be enough for everyone!

by lostmsu

5/31/2026 at 1:43:23 PM

Not to be confused with Da4vid (world-class hacker and owner of the Black sun) or D4vd (rap artist and alleged murderer)

by the__alchemist

5/31/2026 at 8:12:51 PM

I don’t think the chances of confusion between a niche celebrity and a video decoder are very big.

by F3nd0

5/31/2026 at 1:56:43 PM

Or Dave2D, popular tech youtuber

by staindk

5/31/2026 at 2:23:30 PM

Or dave, the command to start Dangerous Dave.

by tosti

5/31/2026 at 2:30:55 PM

> Not to be confused with Da4vid (world-class hacker and owner of the Black sun)

*Da5id

by JoshTriplett

5/31/2026 at 1:05:12 PM

Is codex working on novel decoders 24/7? I hope

by husky8

5/31/2026 at 3:02:08 PM

One would imagine given the name that it would specialize in codecs

by cozzyd

5/31/2026 at 4:52:47 PM

[dead]

by spiral09

5/31/2026 at 1:20:00 PM

When AV1 was first announced, I got the impression the name was chosen partly as a pun/reference/homage to AVI, the classic but outdated format with used to be popular. Then when I saw Dav1d, OK, good way to continue the pun.

But now with AV2 and Dav2d, that completely breaks. Are we eventually going to get AV3/Dav3d and AV4/Dav4d, which will read like Ave/Daved and Ava/Davad? Seems a bit awkward. Was the idea from the start to have the 1 be the version number, and have it specifically be part of the name?

by latexr

5/31/2026 at 4:00:01 PM

I'm pretty sure it is a homage. As for dav1d it's not a reference decoder (although partially funded by AOM iirc) so they might not know that the next iteration will simply be AV2, we have h264, h265, h266 naming though

Tangent but I cannot wait for h269 (or h267 for the younger gen)

by BetterThanSober

5/31/2026 at 3:14:18 PM

I think it's a reasonable decision. The only people who will interact with dav2d by name are codec nerds, and a simple increment makes the lineage more obvious to that audience.

by p1mrx

5/31/2026 at 3:34:16 PM

As with all naming schemes in the tech world, I am sure no future scenarios, including successor names, were ever considered

by xp84

5/31/2026 at 1:30:48 PM

1dav2codecs?

2av2furious?

by jl6

5/31/2026 at 1:51:57 PM

And then AV3: Tokyo Drift, and after that AV Episode 1.

by Hendrikto

5/31/2026 at 3:35:38 PM

Or go the Apple Watch naming scheme route.

Just “AV”

Next, AV Series 1 and 2 (released simultaneously)

Later, AV Edition but it costs $10,000

by xp84

5/31/2026 at 6:14:22 PM

AV360. AV365. AV2030. AVXP. AV8. AV10. Perhaps some here will be around for AV95.

Young AV?

by brnt

5/31/2026 at 2:10:47 PM

Already predicting which versions to avoid, huh.

by BillStrong

5/31/2026 at 1:23:29 PM

> experience Dav... Now in 3D!

by WhrRTheBaboons

5/31/2026 at 1:32:05 PM

Da5id could potentially work as a Snow Crash reference.

by Arubis

5/31/2026 at 4:18:33 PM

I’m fascinated by the flurry of downvotes to a simple commentary and question, especially when the replies are normal. If you’re one of the downvotes, please do share what you found offensive about my comment, I am genuinely interested in what you perceived as problematic.

by latexr

5/31/2026 at 3:35:49 PM

D4vd

by yieldcrv

5/31/2026 at 12:48:56 PM

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?

by poly2it

5/31/2026 at 1:02:39 PM

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

by Arodex

5/31/2026 at 1:22:50 PM

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

by cogman10

5/31/2026 at 6:13:20 PM

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

by dcsommer

5/31/2026 at 8:05:04 PM

> Performance should not be priority #1. Security should be.

For a web browser, or a server in a bank, sure. For anything else, questionable.

> adding a sandbox around a memory-unsafe codec is going to be way more expensive

In modern world, overhead of strong sandboxes is surprisingly small. A nuclear but most reliable option is hardware assisted VM. On modern computers with SLAT and virtualized IO the overhead for most use cases is negligible. If you want something lighter weight, can use a multi-user nature of all modern OS kernels and isolate into a separate process with restricted permissions. Sandboxing overhead is approximately zero.

by Const-me

5/31/2026 at 7:30:03 PM

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

by cogman10

5/31/2026 at 8:51:48 PM

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

by dcsommer

5/31/2026 at 12:57:17 PM

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.

by jbk

5/31/2026 at 7:24:46 PM

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

by cesarb

5/31/2026 at 2:51:46 PM

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.

by LoganDark

5/31/2026 at 3:56:32 PM

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.

by xp84

5/31/2026 at 3:12:35 PM

but not these cases

by throawayonthe

5/31/2026 at 4:35:53 PM

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

by IshKebab

5/31/2026 at 1:30:09 PM

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

by muhbaasu

5/31/2026 at 4:46:14 PM

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.

by nmz

5/31/2026 at 3:16:39 PM

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

by throawayonthe

5/31/2026 at 7:34:54 PM

It is much slower than 5%, there were other independent tests that put it around 20%.

by Thaxll

5/31/2026 at 6:07:27 PM

there's a rav2d now too fwiw — https://github.com/stukenov/rav2d same playbook: safe Rust + asm kernels via FFI. just shipped 0.1.0.

by stukenov

5/31/2026 at 6:07:50 PM

fyi the Rust port already exists: https://github.com/stukenov/rav2d you keep the hand-written asm via FFI, rest is safe Rust. same trick rav1d uses.

by stukenov

5/31/2026 at 12:57:26 PM

Go ask FFmpeg what they're writing their encoders and decoders in.

by Telaneo

5/31/2026 at 1:14:03 PM

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

by latexr

5/31/2026 at 1:42:16 PM

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

by Telaneo

5/31/2026 at 4:15:22 PM

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

by latexr

5/31/2026 at 4:44:39 PM

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

by IshKebab

5/31/2026 at 6:07:05 PM

funny you mention it — rav2d exists now: https://github.com/stukenov/rav2d full C-to-Rust port, asm kernels still via FFI like rav1d does. early (0.1.0) but passes conformance against dav2d.

by stukenov

5/31/2026 at 1:01:31 PM

Yes? There is 5x more code to optimize the ASM for.

by MattRix

5/31/2026 at 2:24:53 PM

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.

by kingstnap

5/31/2026 at 12:39:33 PM

How is AV2 expected to avoid the patent-pool issues AV1 ran into?

AV1 was designed as royalty-free, but Sisvel’s pool and the recent Dolby/Snap proved the contrary.

https://accessadvance.com/2026/03/24/access-advance-licensor...

by Eldodi

5/31/2026 at 12:44:21 PM

They filed a suit, henceforth making a claim of an issue...... They haven't "proved" anything other then they have lawyers on staff that can file some paperwork until the suit is settled in court...

by UnlockedSecrets

5/31/2026 at 12:47:34 PM

How does that prove anything?

They're claiming that there are patents, but that doesn't mean there are.

by AndrewDucker

5/31/2026 at 12:51:33 PM

Dolby is only the most recent case, Sisvel consorsium actually bills licences per device:

Consumer Display Device: EUR 0.32

Consumer Non-Display Device: EUR 0.11

(source here: https://www.sisvel.com/licensing-programmes/audio-and-video-...)

by Eldodi

5/31/2026 at 1:23:42 PM

Sisvel allows you to pay them if you believe their claims, they haven't actually taken anyone not paying to court yet to prove that. The only court cases for VP9/AV1 from Sisvel so far have been their patents being found invalid/irrelevant.

Dolby is somewhat more interesting in that rather than scare tactics, media hype, and attempting to form a pool about it they are actually taking a patent assertion claim to court.

by zamadatix

5/31/2026 at 2:02:55 PM

That crowd are just deeply concerned one of their lucrative revenue streams is disappearing.

So they seem to be attempting to pull a fast one and use unproven claims to try and convert their competitor into a replacement revenue source.

It'll probably be a case of whoever has the best lawyers + contacts + persistence wins.

But it'll be interesting if discovery shows evidence they know they don't have a case and are trying it anyway. "Piercing the corporate veil" can theoretically be a consequence of that AFAIK.

by justinclift

5/31/2026 at 12:53:45 PM

How does how they bill for their product, matter in terms of if their lawsuit holds merit?

by UnlockedSecrets

5/31/2026 at 12:53:12 PM

That doesn’t prove their claims are valid.

I can claim the same and offer licenses per device.

by croes

5/31/2026 at 1:14:52 PM

Can you point to any other patent lawsuit over AV1? AFAIK the Dolby case is the first.

by silotis

5/31/2026 at 12:57:46 PM

Every single AV2 news here in the last week has seen exactly the same question.

Either go back read the answers there first, or I will assume you are part of a FUD campaign (yes, I know HN guidelines, but again every single AV2 news in the last week has seen the same rhetorical "questions" as top "comments").

by Arodex

5/31/2026 at 12:51:59 PM

No codec can ever avoid patent-pool claims.

by croes