181–190 of 212 posts
> Let dav2d be. This is an odd signoff. Are people having a go at dav2d?
"Too Many Requests" - https://web.archive.org/web/20260531130034/https://jbkempf.c... - https://archive.md/ln5UE
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 ```
Earlier quoted context omitted.
> Why shouldn't safety be the default? Because safe code isn't fast enough to decode live video. > 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. Yeah, but then you are undermining safety in a critical way that does lead to security vulnerabilities (buffer overflow). And you are also now maintaining and req…
> Because safe code isn't fast enough to decode live video. I strongly doubt that. And if any implementation of AV2 can be "fast enough", then there should be no question at all that we can write "fast enough" safe decoders for every other codec. Absolutely no way safe code is inherently that much slower.
You can doubt all you like. Ultimately, there's a reason why dav1d includes hand coded SIMD for common platforms.
It's simply impossible to get a compiler to emit something like this [1].
[1] https://github.com/videolan/dav1d/blob/master/src/x86/ipred_...
Earlier quoted context omitted.
Using raw uncompressed bitrate is a bit disingenuous. How about comparing an older, widely supported codec like H.264 as a baseline?
If you compressed it with H.264, it wouldn't make much sense to send it remotely to be encoded with a better codec.
Earlier quoted context omitted.
Who is regularly watching uncompressed videos outside of production environments? That’s got to be a very small population.
The context was remotely encoding the video, which would require sending the uncompressed stream.
I've actually done a version this for some multi-system live AV at an event before. Between the main software mixer workstations at various fields in the event it was a dumb but simple encoding they could do in hardware at a high bitrate and then in the machine compositing for the livestream out it did AV1 software encoding to upload to the streaming site to minimize bandwidth requirement from the venue and maximize quality on the streaming site. We've since upgraded to hardware with AV1 encode though.
The practical downside is AV2 is only providing a 30% advantage over AV1. For the streaming providers their bandwidth costs are pretty cheap compared to revamping the transcoding infrastructure, so it'd probably only make financial sense once the remove end can do the most complex and quality encoding used and the rest are all simpler.
Earlier quoted context omitted.
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.)
For any specific bitrate and quality target, there's a good chance it'll be faster.
Earlier quoted context omitted.
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…
What's supposed to be the big source of unsafety in codecs though? Feels like the problem here is that C developers are ruining the reputation of C with their garbage code. Bounds checking as a source of slowdown is overrated in a niche where you're working on fixed size blocks. It feels like the C developers are getting the parts outside the ASM kernels wrong.
Hand written assembly. It's quite easy to accidentally start reading or manipulating a block of memory you didn't intend to when doing complex SIMD transformations.
> Bounds checking as a source of slowdown is overrated in a niche where you're working on fixed size blocks.
I think you don't really understand how codecs work. It is not uncommon for a transformation like `a = b[c[i] * 3 + offset];`. There's no way for a compiler to omit the bounds check because it can't prove the contents of `c` aren't going to exceed the bounds of `b`.
This isn't a "crappy C developer" problem. This is a "There isn't a language that does a great job at capturing high level SIMD expressions" problem.