We must not continue to develop media codecs in memory unsafe languages. Small, auditable sections can opt-out perhaps, but choosing default-unsafe for this type of software is close to professional negligence.

▲

fguerraz 8 hours ago | parent | next [-]

Cryptography and video codecs are notable exceptions, they put a lot of effort to making the code provably memory safe: no recursion, limited use of stack variables, no dynamic allocations, etc. As a result, memory safe languages bring nothing but trouble by making it non deterministic, that’s especially true for crypto where compiler “optimisations” guarantee you side channels attacks.

▲

WhatIsDukkha 6 hours ago | parent | next [-]

Thank you for mentioning this.

I wonder IFF Rust had an effects system that a Jasmin MIR transform (ie like SPIRV is for shaders) would be useful?

https://github.com/jasmin-lang/jasmin

▲

astrange 4 hours ago | parent | prev | next [-]

Video codecs just don't need to do dynamic allocations because it's not relevant to the problem. There's still certainly plenty of opportunities for memory bugs because there's a lot of pointer math.

▲

simonask 4 hours ago | parent | prev [-]

What in the world do you mean by “non-deterministic”?

C compilers, Rust compilers, and assemblers are all deterministic.

	▲	adgjlsfhk1 13 minutes ago \| parent [-]
		> C compilers, Rust compilers, and assemblers are all deterministic. Within a version, yes, but not cross version. Different versions of GCC/Clang etc can give you completely different code.

▲

fishgoesblub 8 hours ago | parent | prev | next [-]

Of the 3 software AV1 encoders, the only one that is fully dead is the Rust encoder (rav1e). If people truly wanted memory safe encoders/decoders, they would fund and develop them.

▲

vlovich123 7 hours ago | parent | next [-]

Fully dead in what sense? Seems like it still has active development to me.

	▲	fishgoesblub 7 hours ago \| parent [-]
		It hasn't had any proper quality/speed improvements in years. Only thing that has changed is updating deps and some bug fixes.

▲

simonask 4 hours ago | parent | prev | next [-]

Encoding is a way, way less risky thing to be doing compared to decoding.

▲

esseph 8 hours ago | parent | prev [-]

> If people truly wanted memory safe encoders/decoders

Really? How many codecs have your neighbors contributed money for the development of, just curious.

	▲	computerbuster 6 hours ago \| parent \| next [-]
		I think these conversations are directed by the parties funding the efforts. Example: "we (large company) want a fast AV2 decoder" -> they pay a specialized team to do it -> this team works in C for the most part, so it is done in C. If there were financial incentives to do it in Rust, they'd pay more for a Rust decoder.
	▲	Telaneo 7 hours ago \| parent \| prev [-]
		Given Netflix's involvement with SV1-AV1, (not even that) indirectly, at least 1.

▲

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

For the codec itself, the majority of it is performance sensitive and often has a significant amount of assembly even, so a memory safe language doesn't change much.

However for the container/extractor... those should absolutely be in a memory safe language, and those are were a lot of the exploits/crashes are, too, as metadata is more fuzzy.

As a practical example of this see something like CrabbyAVIF. All the parser code is rust, but it delegates to dav1d for the actual codec portion

▲

maxloh 6 hours ago | parent | prev [-]

Decoders written in Rust will be a lot slower than the equivalents in assembly.