4 ms·

What are you even implying?

by Almondsetat 6mo ago

notenlish 6mo ago
I think they mean that video decoders and encoders tend to have custom assembly code for speedup.
- Almondsetat 6mo ago
  And? It's common knowledge that the "reference" or "research" version of any codec is always quite high level to get development going and actually produce a working bitstream
sergiotapia 6mo ago
[flagged]
IshKebab 6mo ago
That codecs should be written in safer languages given that they usually process untrusted files. There have been a number of serious hacks from file parsing bugs due to them being written in unsafe languages. There's literally a DSL designed for this purpose (Wuffs) so it would be interesting to hear why they didn't use it.
- brigade 6mo ago
  There's an order of magnitude difference in speed requirements between file format parsing and image decoding, then another order of magnitude difference to video decoding. Even rav1d reuses dav1d's assembly (most of the actual runtime) to approach its speed.
- adobrawy 5mo ago
  There was already attempt for dav1d to re-implement in rust by rav1d. It was hard to match performance: https://www.memorysafety.org/blog/rav1d-perf-bounty/ https://www.memorysafety.org/blog/rav1d-perf-bounty/
  - IshKebab 5mo ago
    > It was hard to match performance They say it is 5% slower. That's close enough. I know they say it isn't but in reality that speed difference is just going to be used as an excuse by the anti-Rust crowd.
  - hitekker 5mo ago
    Not just performance, the code was littered with unsafe blocks and the benchmarks (IIRC) were gamed heavily by the Rust devs. It was a dishonest effort that actually undermined the memory safety pitch.
- astrange 5mo ago
  The people who write DSLs for video codec asm, or who claim that it's fine to use intrinsics or X higher-level language and it will still be fast enough to be usable, are simply wrong and have never been able to demonstrate otherwise. Having said that I do think you could write a DSL to generate safe performant asm for a video codec. Just not a platform-independent one. It would still have to be asm.
  - dwattttt 5mo ago
    It sounds like your second statement contradicts your first. But also, WUFFS exists and it looks like the Google Chrome GIF decoder ships in it: https://github.com/google/wuffs https://github.com/google/wuffs
    - astrange 5mo ago
      It does not contradict it, and also, a gif is not a video.
      - dwattttt 5mo ago
        > a gif is not a video. They're not that different; the image codec WebP is derived from VP8's intra-frame coding.
        astrange 5mo ago
        I'm well aware and I know the inventor. The important difference for performance is that a gif isn't 60fps.
kergonath 5mo ago
It’s not Rust, therefore it’s bad. Or something. This is getting rather tedious.
- Gigachad 5mo ago
  I don’t think it’s unfounded. Media codecs have been one of the top sources for serious vulnerabilities. The code is incredibly complex, and takes complex input from untrusted sources. Decoders are one of the best places for rust because they are both performance critical and security critical. JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it. And the apps that did utilise the C based libjxl ended up hit with vulnerabilities in it.
  - F3nd0 5mo ago
    > JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it. This is extremely misleading. Before they even started work on the Rust-based decoder, experimental JPEG XL support was added to Chrome and Firefox using the reference C++ implementation. Chrome later removed this support for very dubious claims of lack of interest and improvement over previous generation of codecs. Around that time, Safari shipped JPEG XL support in production, still without the Rust implementation. So the assertion no one wanted to touch it is plain false. It was actually Mozilla who, a long time after stating they were ambivalent on JPEG XL, brought up memory safety as a major consideration, for the very first time. That’s when the work on the Rust implementation started. Since the format continued to be more and more supported and talked about, it’s hard to say what exactly were the factors which made Google reconsider their stance. The notion that somehow everyone was super worried about memory safety from the very beginning, and once the JXL team fixed that, everyone was happy to embrace it, seems to come up a lot lately, but it’s terribly distorted and simply not true.
  - kergonath 5mo ago
    > I don’t think it’s unfounded. Not necessarily. What’s annoying is these low-effort posts that bring nothing. In some contexts the discussion is worth having, but we can do better than "it’s bad because it’s not in my pet language" groupthink.

What are you even implying?

notenlish 6mo ago

I think they mean that video decoders and encoders tend to have custom assembly code for speedup.

Almondsetat 6mo ago
And? It's common knowledge that the "reference" or "research" version of any codec is always quite high level to get development going and actually produce a working bitstream

sergiotapia 6mo ago

[flagged]

IshKebab 6mo ago

That codecs should be written in safer languages given that they usually process untrusted files. There have been a number of serious hacks from file parsing bugs due to them being written in unsafe languages. There's literally a DSL designed for this purpose (Wuffs) so it would be interesting to hear why they didn't use it.

brigade 6mo ago
There's an order of magnitude difference in speed requirements between file format parsing and image decoding, then another order of magnitude difference to video decoding. Even rav1d reuses dav1d's assembly (most of the actual runtime) to approach its speed.
adobrawy 5mo ago
There was already attempt for dav1d to re-implement in rust by rav1d. It was hard to match performance: https://www.memorysafety.org/blog/rav1d-perf-bounty/ https://www.memorysafety.org/blog/rav1d-perf-bounty/
- IshKebab 5mo ago
  > It was hard to match performance They say it is 5% slower. That's close enough. I know they say it isn't but in reality that speed difference is just going to be used as an excuse by the anti-Rust crowd.
- hitekker 5mo ago
  Not just performance, the code was littered with unsafe blocks and the benchmarks (IIRC) were gamed heavily by the Rust devs. It was a dishonest effort that actually undermined the memory safety pitch.
astrange 5mo ago
The people who write DSLs for video codec asm, or who claim that it's fine to use intrinsics or X higher-level language and it will still be fast enough to be usable, are simply wrong and have never been able to demonstrate otherwise. Having said that I do think you could write a DSL to generate safe performant asm for a video codec. Just not a platform-independent one. It would still have to be asm.
- dwattttt 5mo ago
  It sounds like your second statement contradicts your first. But also, WUFFS exists and it looks like the Google Chrome GIF decoder ships in it: https://github.com/google/wuffs https://github.com/google/wuffs
  - astrange 5mo ago
    It does not contradict it, and also, a gif is not a video.
    - dwattttt 5mo ago
      > a gif is not a video. They're not that different; the image codec WebP is derived from VP8's intra-frame coding.
      - astrange 5mo ago
        I'm well aware and I know the inventor. The important difference for performance is that a gif isn't 60fps.

kergonath 5mo ago

It’s not Rust, therefore it’s bad. Or something. This is getting rather tedious.

Gigachad 5mo ago
I don’t think it’s unfounded. Media codecs have been one of the top sources for serious vulnerabilities. The code is incredibly complex, and takes complex input from untrusted sources. Decoders are one of the best places for rust because they are both performance critical and security critical. JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it. And the apps that did utilise the C based libjxl ended up hit with vulnerabilities in it.
- F3nd0 5mo ago
  > JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it. This is extremely misleading. Before they even started work on the Rust-based decoder, experimental JPEG XL support was added to Chrome and Firefox using the reference C++ implementation. Chrome later removed this support for very dubious claims of lack of interest and improvement over previous generation of codecs. Around that time, Safari shipped JPEG XL support in production, still without the Rust implementation. So the assertion no one wanted to touch it is plain false. It was actually Mozilla who, a long time after stating they were ambivalent on JPEG XL, brought up memory safety as a major consideration, for the very first time. That’s when the work on the Rust implementation started. Since the format continued to be more and more supported and talked about, it’s hard to say what exactly were the factors which made Google reconsider their stance. The notion that somehow everyone was super worried about memory safety from the very beginning, and once the JXL team fixed that, everyone was happy to embrace it, seems to come up a lot lately, but it’s terribly distorted and simply not true.
- kergonath 5mo ago
  > I don’t think it’s unfounded. Not necessarily. What’s annoying is these low-effort posts that bring nothing. In some contexts the discussion is worth having, but we can do better than "it’s bad because it’s not in my pet language" groupthink.