8 ms·
Rav1e: An experimental AV1 video encoder, designed to be fast and safe
- kristofferR 8y agoWhat does "safest" mean in this context?
- AndrewDucker 8y ago"Written in Rust"
- blitmap 8y agoI'm trying to get my insurance discounted on my car. I should slap a "written in Rust" sticker on it. Safe driver discount?
- pleasecalllater 8y agoIt makes sense. If your car is covered with rust, you should be almost sure that no one will even try to steal it. :)
- Crespyl 8y agoGiven that automotive control software is apparently a huge mess right now, and a rapidly growing attack surface, a more disciplined rewrite in Rust might actually be enough for an insurance company to consider...
- CUViper 8y agoPDXRust just had a related talk, "Writing Software That's Safe Enough To Drive A Car": https://www.meetup.com/PDXRust/events/252160920/ https://www.meetup.com/PDXRust/events/252160920/
- jabl 8y agoPresumably that it's implemented in Rust, and thus does not suffer from many of the usual bugs that C code bases suffer from? There seems to be some asm code as well, which obviously does not enjoy the safety advantages of Rust.
- arez 8y agoI always wondered if in practice it really checks out, is rust code really safer? Did the bugs just shift to different ones? Is there anyone who wrote about that already?
- masklinn 8y agoIt's probably not quite equivalent but I believe Frederico & al found & fixed a number of issues when they converted librsvg to rust. You may want to check the archives on their blogs (IIRC it's split between Frederico's own and the librsvg one) for more, or specifics. But "safe" rust at least intrinsically protects from use-after-free, double free, dangling pointers, null-pointer dereferences, out-of-bounds accesses, … You may still have logic bugs of course (though the richer type system expressivity also allows better static encoding of application & domain logic), but these baseline memory-safety issues will only be a problem in specific and tagged `unsafe` blocks rather than throughout the application.
- kevincox 8y agoWhile I do believe that rust will prevent many memory safety issues. I think you would probably catch a bunch of safety issues rewriting any code.
- deleted 8y ago[deleted]
- zakk 8y ago> ~5 fps encoding @ 480p How does this compare with the reference encoder?
- masklinn 8y agoYou'd need to run them on the same machine to make sure you get a proper comparison but https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=5601 https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=5601 has some runs. One of the users downthread ("entac") provides both libaom and libx264 numbers, they get 63fps for libx264 and 0.0924fps for libaom (r9028) Also this currently does delegates work to libaom.
- tatref 8y agoThe readme didn't specify the --release flag in the cargo run command, this should make a pretty big difference
- steveklabnik 8y agoI sent a PR; as they merged, they mentioned their test scripts use it...
- skolemtotem 8y agoWill AV1, or even VP9 for that matter, ever be suitable for realtime encoding, or is that just not their target market?
- masklinn 8y agoAFAIK realtime encoding is a design consideration for AV1.
- dash101 8y agoFREE Classifieds http://www.f1mint.com/ http://www.f1mint.com/
- JustFinishedBSG 8y agoWell eventually we'll get AV1 hardware encoding so I'd say in 5 years smartphones will encode AV1 in real time
- matt4077 8y agoYes, of course. Anything else would be DOA. On a general note: there really seems to be an extremely inaccurate narrative regarding AV1 and speed taking hold. I can't understand why it isn't easier understood that a reference implementation is about accuracy only, completely ignoring performance considerations. Not in the usual "we'll now try to make it faster", but as in "this is never meant to be used in production, and it's performance is in no way indicative of the performance optimised encoders will see". As but one example: media encoding is pretty close to being "embarrassingly parallel" in principle, making the first three orders of magnitude easy wins for a straightforward GPU implementation.
- Ienuur4i 8y ago> media encoding is pretty close to being "embarrassingly parallel" in principle My understanding is that there are some fairly tight feedback loops in the encoders that make it difficult to offload things to the GPU, at least if you want to maximize the quality per byte metric. If you want to target realtime and don't need optimal compression it probably gets easier.
- sargun 8y agoJust curious, what's the memory footprint on the encoder in real life? Do different video encoders, for the same codec, and input produce different outputs, or is the algorithm specified in a way where it produces the same results for two given inputs, no matter what?
- TD-Linux 8y agoVirtually all of the consumed memory is from the reference frames, so it depends on how big your video is. AV1 supports up to 8 reference frames, though if you're memory constrained you could use less. Different encoders produce different outputs, the algorithm isn't specified.
- wolf550e 8y agoFor almost all compression algorithms (both lossless and lossy), only the decompression is specified. A compressor can do whatever it wants as long as it produces a bitstream that a compliant decompressor can decode. For example, you can make a video enocoder that produces a compliant video stream in which every frame is a keyframe and every macroblock is independently fully encoded, thus reducing AV1 (or H265, etc.) to MJPEG. But if the result is decodable by a compliant decoder, your compressor is compliant. It might even be somewhat useful (e.g. output needs to be zero latency or output is intended to be edited).
- tzahola 8y agoAnd this is how people keep making substantial improvements to ancient formats like JPEG or MP3. E.g. Guetzli from Google: https://github.com/google/guetzli/blob/master/README.md https://github.com/google/guetzli/blob/master/README.md
- Pissompons 8y ago> Do different video encoders, for the same codec, and input produce different outputs, or is the algorithm specified in a way where it produces the same results for two given inputs, no matter what? Someone else answered this but I thought I'd elaborate: A good way to think about a codec is as a toolbox. The specification tells you which tools you can use to build a frame (encoder) and which you must support to turn one into pixels (decoder). Which tools are used in what way makes a huge difference in the output of the encoder, particularly in terms of compression. Have a look at the results for a few H.264 encoders [0]. For the "video conferencing" use-case, the best encoder (x264) uses ~400kbps to produce the same quality of the worst at ~1000kbps. And like different tools have different costs (a jackhammer needs a generator, a handheld hammer does not), so do the tools in the codec toolbox. Some tools might make the encode slower or might make the decode drain more battery from a mobile device. Others might take a lot of physical space on a piece of silicon, so they're rarely used in hardware. So different encoders have very different characteristics, not just in terms of output but in terms of power usage, speed and complexity as well. [0]: http://www.compression.ru/video/codec_comparison/h264_2012/ http://www.compression.ru/video/codec_comparison/h264_2012/