22 ms·
Rav1e, an AV1 encoder written in Rust and assembly
- saagarjha 6y agoAny major projects using this yet?
- mindfreeze 6y agoVimeo: Vimeo's staff pick is encoded using rav1e, FFmpeg is having it
- mindfreeze 6y agohttps://medium.com/vimeo-engineering-blog/behind-the-scenes-of-av1-at-vimeo-a2115973314b https://medium.com/vimeo-engineering-blog/behind-the-scenes-... https://vimeo.com/blog/post/av1-new-standard-codecs/ https://vimeo.com/blog/post/av1-new-standard-codecs/
- FullyFunctional 6y agoGreat link (and I love Vimeo). The blog goes hyperbolic though: "In other words, if you happen to be in a part of the world where you might not have the best internet connection, AV1 will still provide you with an impeccable viewing experience." No, AV1 is evolutionary. You'll "just" better quality for the same amount of bits (just like going from MPEG2 -> H.264 -> H.265 etc). The license of AV1 however is revolutionary.
- trp1 6y agoIs there a way to use this in ffmpeg yet or is it just stand alone application?
- mindfreeze 6y agoFFmpeg master is having for a while now, if you could grab latest nightly, you can use it. https://ffmpeg.org/ffmpeg-codecs.html#librav1e https://ffmpeg.org/ffmpeg-codecs.html#librav1e
- Daemon404 6y agoI would perhaps wait until rav1e 0.4, because there is a bug in the FFmpeg wrapper (of which I am the author) right now that breaks timestamps. If you wish to build with rav1e master, you can apply this to fix it: https://github.com/dwbuiten/FFmpeg/commit/ac4cf898c1960d72bce2966592cc2933d229f79c https://github.com/dwbuiten/FFmpeg/commit/ac4cf898c1960d72bc... (removing the configure check) It hasn't made it upstream yet since I can't bump the minimum required version in FFmpeg git until rav1e tags 0.4.
- MaxBarraclough 6y agoInteresting that they do it only on the staff pick videos. I presume this is a way of incrementally rolling out support for the codec.
- muglug 6y agoYes.
- jjcm 6y agoYouTube: https://www.flatpanelshd.com/news.php?subaction=showfull&id=1588740730 https://www.flatpanelshd.com/news.php?subaction=showfull&id=... Netflix: https://netflixtechblog.com/netflix-now-streaming-av1-on-android-d5264a515202 https://netflixtechblog.com/netflix-now-streaming-av1-on-and...
- pkulak 6y agoIs it multithreaded???
- mindfreeze 6y agoYes, by default it is, You can use `--threads` to hack around, We are using Rayon for multi threading, and also tiling to boost the output
- pkulak 6y agoWonderful. Thanks!
- blattimwind 6y agoYou can't make a competitive video encoder that isn't.
- pkulak 6y agoI see you haven't tried encoding AV1 with FFMPEG lately.
- Erlangen 6y ago> The fastest and safest AV1 encoder. Is it faster than dav1d?
- mindfreeze 6y agodav1d is a decoder while rav1e is an encoder rav1e = rav1e is an AV1 Encoder dav1d = dav1d is an AV1 Decoder
- deathgrips 6y agoCoders can't come up with a good name to save their lives.
- Already__Taken 6y agoEav1e was right there as well :(
- StavrosK 6y agoWhat's your proposal?
- deathgrips 6y agoSince I am a fellow coder I cannot in good conscience suggest another terrible name.
- danielheath 6y agoHow about “encodeav1” for the cli tool, “libav1encoder-rs” for the library crate.
- lukevp 6y agoFor others like me who are curious and haven't heard of AV1, some main features: * Open & Royalty Free (no licensing required to use) * Backed by Mozilla, Google, Microsoft, Cisco, etc. [1] * Approximately 50% higher compression than x264 [1] and 30% higher than H.265 (HEVC) [2] * Supported in current versions of Chrome, Firefox, Opera, and Edge [3] * Slower encoders than HEVC, so not typically used for live streaming [2] [1]: https://en.wikipedia.org/wiki/AV1 https://en.wikipedia.org/wiki/AV1 [2]: https://www.theoplayer.com/blog/av1-hevc-comparative-look-video-codecs https://www.theoplayer.com/blog/av1-hevc-comparative-look-vi... [3]: https://caniuse.com/#feat=av1 https://caniuse.com/#feat=av1
- dindresto 6y agoAs far as I know, WebM only recently added AV1 support to its container format. Before that, it was already supported in MP4 and Matroska.
- lukevp 6y agoThanks, I removed the reference to WEBM in that case. MP4 and MKV are very common container formats, so being supported in WEBM, MP4, MKV doesn't seem like a differentiator.
- m-p-3 6y agoWith how versatile the MKV container is, it seems odd that it isn't the de facto container out there.
- fireattack 6y agoNot to mention WebM is (was?) literally a subset of Matroska.
- namibj 6y agoAfaik WebM is just a royalty-free subset of MKV, maybe with some exotic features omitted.
- Ptilopsis 6y agoWith AV1 encoders I have to ask myself every time whether I should read the 1 as 'i' or as 'l'. Dav1d was still easy to guess, but here I really have a hard time. Apart from that, I am really glad to see how Rust is slowly making an appearance in such fundamental multimedia libraries.
- PBnFlash 6y agoA V ONE AVI is already a container so it would just be confusing.
- StavrosK 6y agoI think he means "ravie" or "ravle".
- noisem4ker 6y ago"Ravie" https://youtu.be/ytsRYKQc6kQ https://youtu.be/ytsRYKQc6kQ
- Flow 6y agoI see that Safari does not support this (yet). Might it be possible to compile this to wasm and decode it that way on the client?
- ducaale 6y agoIs Safari becoming the new Internet Explorer?
- londons_explore 6y agoIt has been for a long time... It's opensource even, but they seem to ignore patches
- saagarjha 6y ago(To be pedantic: Safari is closed source, the WebKit that ships with Safari is mostly open source.)
- Wowfunhappy 6y agoHow different is this than Google Chrome being closed vs Chromium being open? Does Safari have more substantial closed-source components?
- saagarjha 6y agoChromium basically ships with a usable, “de-Googled” browser in tree doesn’t it? WebKit has what you might call a demo. Look up MiniBrowser to see what I mean. It’s a web view and three buttons, basically.
- Wowfunhappy 6y agoWhat about the Webkit Nightly builds though? Those basically seem to be Safari.
- kzrdude 6y agoHow is there constantly so much compression ratio improvement in video codecs? New algorithms imrpove so much upon the old.
- aaronblohowiak 6y ago“Compression is understanding”. As our understanding of the problem domain increases, so too will our ability to compress it. Video has three key things: the still images that approximate the input, the relationship of one image to the prior and next and a human bean who is sensitive to some kinds of distortion and not others, depending on context :) To have effective and good compression, you have to understand all three. Note: while I work at Netflix, I do not work on anything related to video encoding, these are just my semi-informed understandings :)
- sephamorr 6y agoI would also add computational complexity. We're increasingly willing to throw more transistors at video decoding and encoding due to their reduced cost and increased performance, so the algorithms can become more complicated, have larger perform larger searches, etc. If you think about it from a power perspective, the power cost of a bit of data transmitted to a mobile device is pretty large. I would expect to see video compression formats increase in complexity until the power cost of compressing away one more bit approaches the cost of transmitting one more bit over the network.
- aaronblohowiak 6y agoWell with the compression vs transmission/decompression ratio of video for stuff in the Netflix catalog, I think the inflection point is different than you suggest (not sure about YouTube.)
- sephamorr 6y agoYou're right. I was thinking about the decoding side (where total power for displaying the video should be minimized) but was unclear above.
- natemcintosh 6y ago"The fastest and safest AV1 encoder" but it's also 62.1% assembly? Is the assembly as safe as rust? I'm confused
- the_mitsuhiko 6y agoThe assembly appears to be optional.
- tptacek 6y agoIs it still the safest when it's the fastest, or do you have to pick?
- ZeroGravitas 6y agoDespite the tagline, I don't think its ever actually been the fastest AV1 encoder, it's quite possible its always the safest, even with the asm in place and even more so when using only rust.
- cryptoquick 6y agoRust can compile to many different targets. The assembly is for x86 platforms, but this project also supports arm64 and wasm targets. If security is of utmost concern, I would actually suggest running the WASM build in a sandboxed JIT like lucet.
- spullara 6y agoRust? Not really. https://github.com/xiph/rav1e/search?q=unsafe&unscoped_q=unsafe https://github.com/xiph/rav1e/search?q=unsafe&unscoped_q=uns...
- ZeroGravitas 6y agoI've not checked the actual numbers but I think in terms of line count, that assembly may be the same function done multiple times for different (sub-)architectures for different generations of Arm and Intel chips that have different vector instructions.
- Thaxll 6y ago"The fastest and safest AV1 encoder." quick search on unsafe: https://github.com/xiph/rav1e/search?q=unsafe&unscoped_q=unsafe https://github.com/xiph/rav1e/search?q=unsafe&unscoped_q=uns... https://github.com/xiph/rav1e/issues/2378 https://github.com/xiph/rav1e/issues/2378 https://github.com/xiph/rav1e/issues/2310 https://github.com/xiph/rav1e/issues/2310 Does not seems safe at all, definitly not the "safest"encoder out there.
- dan-robertson 6y agoThe rust standard library is full of uses of unsafe. Does that mean it is not a safe library? No one uses “unsafe” in C (because it doesn’t exist). Does that mean C libraries are safe? Is there some safer encoder you have in mind?
- weinzierl 6y agoJust because the source has unsafe blocks doesn't mean it is unsafe either. At least the amount of work to check these blocks for memory issues is a lot less then checking any other implementation.
- IshKebab 6y agoAren't the only other encoders written in C?
- mcraiha 6y agoSVT-AV1 is written in C (and lots of assembly). libaom-av1 is written in C (and lots of assembly). libgav1 (which is decoder) is written in C++ (and lots of assembly). So yes, lots of C/C++ in open source AV1 encoders/decoders.
- IshKebab 6y agoSo it sounds to me like it might be the safest encoder... except for the fact that it is 60% assembly. Maybe they can improve that.
- dang 6y agoSee also 2018 https://news.ycombinator.com/item?id=17539361 https://news.ycombinator.com/item?id=17539361 2019 https://news.ycombinator.com/item?id=19746392 https://news.ycombinator.com/item?id=19746392
- devwastaken 6y agoWe really need focus on embedded GPU av1 as well. It's amazing how fast pure GPU transcoding is. H265 is supported well in modern GPU's and can transcode at dozens of times the speed. But av1 for some reason isn't getting the same treatment is seems.
- th3typh00n 6y agoGPU:s are generally terrible for video encoding. I think you're confusing the GPU with a dedicated "hardware encoder" ASIC (which may be located on the same die as other silicon components such as a CPU or a GPU).
- fluffything 6y agoAn off-the-shelf GPU can encode / decode thousands of channels of video and audio in real-time. There are some cloud providers that offer this as a service, allowing you to have the end-points of, e.g., video calls to use different audio and video codecs. This is quite useful, e.g., when some people join the call only using audio via a cell phone in a different country using a different audio standard (or a land line, etc.). Or when somebody joins the video call from laptop tethering from a phone on a train. Or for switching video codecs depending on whether somebody is sharing their desktop or using a webcam to record their face. The client can picks the codecs that are the best fit for the current situation (content, bandwidth, latency, etc.) and a could server transcodes the video from everyone else in the meeting to their clients format.
- robert_foss 6y agoThe point the parent poster was trying to make was that the GPU cores themselves are not a great match for video codec work. However most consumer/server GPUs include hardware IP blocks specifically for doing codec work.
- fluffything 6y agoAnd that point is wrong, since there are some cloud providers using normal GPU cores for exactly this. The codecs that NVEnc supports are just a few bunch, there is no real-time audio, no nothing. All of this is implemented in CUDA, using normal CUDA implementations of audio and video codecs, and running on normal GPUs using normal GPU cores. In real time. Supporting thousands of audio and video channels concurrently. Also, even for NVEnc and NVDec themselves, in some of the GPUs they do not use any specialized hardware and use normal GPU cores instead (e.g. see the older GM20x GPUs).
- jimmar 6y agoThe developers say it's the fastest, but does anybody have a link to benchmarks?
- loeg 6y agoAnyone know how the "fastest" claim stacks up against SVT-AV1?
- mcraiha 6y agohttps://www.researchgate.net/publication/340351958_MSU_Video_Codec_Comparison_2019_part_IV_High-Quality_Encoding_aom_rav1e_SVT-AV1_SVT-HEVC_SVT-VP9_x264_x265_ENTERPRISE_VERSION https://www.researchgate.net/publication/340351958_MSU_Video... according to that (5. ENCODING SPEED section) SVT-AV1 is a bit faster, but since they are both VERY slow it doesn't really matter. That was released in March so recent updates might have changed things.
- loeg 6y agoThanks.
- LockAndLol 6y agoIs it worth using as a default encoder for home movie libraries? Or would it soebd the next decade encoding everything?