Live data from Hacker News

Rav1e: An experimental AV1 video encoder, designed to be fast and safe

github.com

41–50 of 76 posts

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#41

Will AV1, or even VP9 for that matter, ever be suitable for realtime encoding, or is that just not their target market?

I actually had a realtime rav1e demo running, with some modifications. There's nothing inherently less realtime about AV1 than, say H.264.

There are a number of features that make AV1 structurally more suited to real-time implementations than its predecessor, VP9.

For example, it does adaptive entropy coding instead of explicitly coding probabilities in the header. That means that you don't need to choose between making multiple passes over the frame (one to count symbol occurrences and one to write the bitstream using R-D optimal probabilities) or encoding with sub-optimal probabilities (which can have an overhead upwards of 5% of the bitrate). libaom has always been based on a multi-pass design, as was libvpx before it, but rav1e only needs a single pass per frame (we may add multiple passes for non-realtime use cases later).

In another example, AV1 has explicit dependencies between frames. VP9 maintained multiple banks of probabilities which could be used as a starting point for a new frame. But any frame was allowed to modify any bank. So if you lost a frame, you had no idea if it modified the bank of probabilities used by the next frame. In AV1, probabilities (and all other inter-frame state) propagate via reference frames. So you're guaranteed that if you have all of your references, you can decode a frame correctly. This is important if you want to make a low-latency interactive application that never shows a broken frame.

Some of its tools also become more effective in low-complexity settings. One of the new loop filters, CDEF, gives somewhere around a 2% bitrate savings using objective metrics when tested with libaom running at its highest complexity (although subjective testing suggests the actual improvement is larger). However, when you turn down the complexity, the improvement from CDEF goes up to close to 8%. I.e., using this filter helps you to take shortcuts elsewhere in the encoder.

The real reason the reference encoder is so slow is that it searches a lot of things. You can always make things run faster by searching less. Take a look at http://obe.tv/about-us/obe-blog/item/54-a-look-at-the-bbc-uh... to see how drastically people are limiting HEVC to make it run in real time today (though if you have to go up to 35 Mbps to do so, one might wonder what the point is).

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#42
post #38

Just 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?

For 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).

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#43
post #40

Earlier quoted context omitted.

You can divide the video into chunks and encode the chunks in parallel. This is what Netflix does: https://medium.com/netflix-techblog/high-quality-video-encod... https://medium.com/netflix-techblog/dynamic-optimizer-a-perc... Works well when you're doing video at the scale of Netflix, but not necessarily much help to the individual user who just wants to encode a video.

> You can divide the video into chunks and encode the chunks in parallel. What about live encoding?

You can split the encoding across 32 cores:

https://bitmovin.com/constantly-evolving-video-landscape-dis...

https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live...

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#44
post #38

Just 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?

> 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/

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#45
post #38

Just 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?

For 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.)…

And 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

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#46

Will AV1, or even VP9 for that matter, ever be suitable for realtime encoding, or is that just not their target market?

Yes, 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…

Video compression engineer here.

> I can't understand why it isn't easier understood that a reference implementation is about accuracy only, > completely ignoring performance considerations.

Because the official codebase conveys another message. Have a look, there are SIMD implementations for almost all supported targets.

https://aomedia.googlesource.com/aom/+/av1-normative/aom_dsp... https://aomedia.googlesource.com/aom/+/av1-normative/aom_dsp... https://aomedia.googlesource.com/aom/+/av1-normative/aom_dsp... ....

What are these files for, if not performance? They've been maintained and kept synchronized with the reference C code during the whole project, long before the codec was frozen (and it was a huge PITA).

This doesn't look like "completely ignoring performance considerations".

> As but one example: media encoding is pretty close to being "embarrassingly parallel" in principle,

Almost all video codecs exploit some block-level encoding context, which means the way you encode one block depends on how the previous neighbooring blocks were encoded. This creates a huge dependency between blocks. There are tools like slicing/tiling that allow you to break these dependencies, and thus, encoding in parallel, but at the cost of video quality. Making the problem "embarrassingly parallel" at this point would make the video "embarrasingly ugly".

You could encode multiple frames in parallel ; but then again, being able to encode them independently means you're basically trashing all the compression context (reference frames), and your video quality goes down the tubes.

In an offline encoding scenario (Netflix, Youtube), if you have lots of memory, you can encode multiple independent video sequences from the same movie. Making the problem "embarrassingly parallel" in this case would require an "embarrassingly huge" amount of memory. Also, it's not applicable to a live scenario (think: latency).

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#47
post #29
post #6

Earlier quoted context omitted.

I 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?

> I always wondered if in practice it really checks out, is rust code really safer? Did the bugs just shift to different ones? Bugs don't magically "shift". If you eliminate a class of bugs, it's gone (e.g. memory bugs). Whether you can still have other bugs (e.g. logic bugs) that's irrelevant, you could still have those in C as well.

>Bugs don't magically "shift".

It depends... You can’t have dangling pointers in Java - instead, you can “leak” memory by holding onto your objects even when they’re not needed anymore.

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#48
post #33
post #30

Earlier quoted context omitted.

> Yes, but not only Rust, rather any memory safe system programming language all the way back to ESPOL in 1961. Yes, but now we're discussing only those that practically matter to more than 5 people today.

I bet Unisys MCP deployments still matter to more than 5 people. Plus the point was to talk about safe systems programming languages in general. Or should we ignore history just because UNIX won on the server?

What’s this “UNIX”? A Linux distribution?

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#49
post #36

Earlier quoted context omitted.

> As but one example: media encoding is pretty close to being "embarrassingly parallel" in principle Which part? 90% of what you're doing is context or inter-frame dependent. Video encoders that live on graphics cards today use dedicated ASIC hardware.

You can divide the video into chunks and encode the chunks in parallel. This is what Netflix does: https://medium.com/netflix-techblog/high-quality-video-encod... https://medium.com/netflix-techblog/dynamic-optimizer-a-perc... Works well when you're doing video at the scale of Netflix, but not necessarily much help to the individual user who just wants to encode a video.

> You can divide the video into chunks and encode the chunks in parallel

You can do this with zlib too (zlib divides a file up into 64k chunks). Doesn't mean that zlib is well-suited for GPUs, nor is each chunk "embarrassingly parallel". Neither Netflix post talks about using the GPU at all.

Re: Rav1e: An experimental AV1 video encoder, designed to be fast and safe

#50
post #38

Just 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?

Different video encoders certainly produce different outputs. Even the same video encoders produce different outputs. Here is a good paper that explains why that is, and talks about how to make a deterministic video h264 encoder:

http://www.ndsl.kaist.edu/~kyoungsoo/papers/mmsys14.pdf

Post reply on HN