I can totally understand why people would want a memory-safe decoder, but a memory-safe encoder is niche. Finding a memory-safety bug in a decoder is a matter of finding a single unchecked integer field somewhere; finding a memory-safety bug in an encoder requires first finding some sort of logic bug in the encoder and then crafting an adversarial input that survives a number of highly lossy transformations.
replyCompare the number of CVEs against x264 (included decoders don't count!) and FFmpeg's H.264 decoder.
https://github.com/memorysafety/rav1d got funded and developed. it is unfortunately a bit slower (typically by a single-digit percentage) than dav1d.
replyEncoding is a way, way less risky thing to be doing compared to decoding.
replyFully dead in what sense? Seems like it still has active development to me.
replyIt hasn't had any proper quality/speed improvements in years. Only thing that has changed is updating deps and some bug fixes.
replyThere are many paths to memory safety, even if the one Rust project seems to be going nowhere.
replyThere's other memory-safe languages, and there's formal verification.
e.g. seL4 favors pancake.
> If people truly wanted memory safe encoders/decoders
replyReally? How many codecs have your neighbors contributed money for the development of, just curious.
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.
replyGiven Netflix's involvement with SV1-AV1, (not even that) indirectly, at least 1.
reply