What are you even implying?

kergonath 4 hours ago | parent | next [-]

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

	▲	Gigachad 2 hours ago \| parent [-]
		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.

▲

notenlish 7 hours ago | parent | prev | next [-]

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

	▲	Almondsetat 6 hours ago \| parent [-]
		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

▲

IshKebab 7 hours ago | parent | prev | next [-]

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 7 hours ago | parent | next [-]

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 5 hours ago | parent | prev | next [-]

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/

▲

astrange 5 hours ago | parent | prev [-]

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 3 hours ago | parent [-]

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

	▲	astrange 23 minutes ago \| parent [-]
		It does not contradict it, and also, a gif is not a video.

▲

sergiotapia 7 hours ago | parent | prev [-]

[flagged]