View Full Version : Xiph Rav1e: Rust AV1 encoder
foxyshadis
8th February 2020, 07:47
The fastest and safest AV1 encoder.
rav1e is an AV1 video encoder. It is designed to eventually cover all use cases, though in its current form it is most suitable for cases where libaom (the reference encoder) is too slow.
https://github.com/xiph/rav1e/
Features
Intra and inter frames
64x64 superblocks
4x4 to 64x64 RDO-selected square and 2:1/1:2 rectangular blocks
DC, H, V, Paeth, smooth, and a subset of directional prediction modes
DCT, (FLIP-)ADST and identity transforms (up to 64x64, 16x16 and 32x32 respectively)
8-, 10- and 12-bit depth color
4:2:0 (full support), 4:2:2 and 4:4:4 (limited) chroma sampling
Variable speed settings
Near real-time encoding at high speed levels
Current release: 0.3.0 (2020-02-06)
foxyshadis
8th February 2020, 07:49
Rav1e Release v0.3.0: FOSDEM Edition
https://github.com/xiph/rav1e/releases/tag/v0.3.0
Improvements
Faster and better Speed 10
Smaller binaries (Around 3MB stripped on x86_64/Linux)
Faster build times (About 14% faster build time)
Multi-threaded deblocking filter
Additional x86_64 SIMD code
More auto-vectorizable codepaths and bounds check elisions
⅙ less memory allocations
Improvements on the intra-modes pruning logic in the RDO
More float to fixed-point conversions
Make an early-exit condition in RDO faster
Simplify logic in Counter/Recorder store method
Support wasm32-wasias build target.
New tools
Intra edge filter
Switch frame support (use -S, --switch-frame-interval <SWITCH_FRAME_INTERVAL>to enable it from the CLI)
Fine directional intra prediction
Still Picture support (AVIF)
Changes
Upstream nasm-rs 0.1.7 can be used to build rav1e.
The C header produced is now C++-compatible
Kurtnoise
14th January 2021, 18:25
Rav1e Release v0.4.0
https://github.com/xiph/rav1e/releases/tag/v0.4.0
Improvements
Enable open partitions on frame boundaries (2% improvement to coding efficiency)
Use av-metrics in CLI to compute PNSR, PSNR-HVS, SSIM, MS-SSIM, and CIEDE2000 (see --metrics)
Enable deblocking in loop filter rate-distortion optimization (0.5% to 1.5% improvement to coding efficiency)
Thread CDEF loop filter with tiles (1.2% reduction in encoding time with 4 tiles)
Redesign the rate control API
Add monochrome support
Improve 4:2:2 support (37% reduction in encoding time, 0.8% to 5% improvement to coding efficiency)
Add compound prediction mode variants for drl=2 and drl=3
Enable NEAR_NEAR1MV and NEAR_NEAR2MV compound modes
Support arbitrary-SAR anamorphic video
Enforce a frame limit of 1 in still picture mode
Add a quiet mode to the CLI (--quiet flag)
Convert all motion vector predictors to full pixel precision
Update non-broken motion estimation predictors (0.28% improvement to coding efficiency)
Substantially rework initial motion estimation (9% reduction in encoding time)
Optimise predictors for multipass motion estimation (0.3% to 0.4% improvement to coding efficiency)
Optimize chroma quantizer offsets for 4:4:4 sampling
Allow opaque extra data to be attached to frames and retrieved from encoded packets via the API
Merge new dav1d assembly code for x86 and AArch64
Add/improve assembly code for distortion computations
Derive quantizers using linear models (0.7% to 1.7% improvement to coding efficiency)
Prune intra frame prediction mode list dynamically (5.5% to 12.2% reduction in encoding time at speed level 5)
Optimize rate-distortion optimization loop (1% reduction in encoding time)
Reduce memory allocation count in various areas
Optimize tile block access (1.5% reduction in encoding time)
Allow frame sizes <16x16 in still picture mode
Add high bit depth AVX2 assembly (9% to 31% reduction in encoding time for 10-bit video)
Bug Fixes
Fix rebuilding with fresh assembly output
Fix the chroma plane desyncs on narrow frames
Abort rate controlled encoding without a bitrate target in the CLI
Fix the -v CLI option
Fix a crash when using 4 tiles for 1080p 4:2:2 input
Fix intra edge filter desyncs with 4:2:2 and 4:4:4 input
Fix a symbol redefinition error for AArch64 builds using Clang
Fix loop restoration filter with 4:2:2 and 4:4:4 input
Fix incorrect quantizer index clamping
Fix cross-compiling for mingw-W64 on macOS
Avoid a buffer underflow condition in CDEF pad_into_tmp16()
Properly validate minimum RDO lookahead frames value
Respect quantizer bounds with rate control enabled
Restrict still picture mode to single-frame streams
Changes
Bump minimum version of NASM to 2.14.02
Update speed presets
Enable full SGR search for levels 0-4 instead of 0-8
Enable fine directional prediction for all speed levels
Enable reduced transform type search for levels 6-10 instead of 5-10
Disable transform type RDO for inter frames
Rename "native" CPU feature level to "Rust" (use RAV1E_CPU_TARGET=rust at runtime)
Remove in-library PSNR computation feature
Move frame-related data structures to a separate crate (v_frame)
Extend dump_lookahead_data feature
Export the frame_subtype property
Use the RAV1E_DATA_PATH environment variable to determine the output path
Refactor CDEF to allow easier importation of dav1d CDEF assembly, as well as simplifying interaction between loop filters
Remove leftover code ported from libaom
Remove unused diamond motion estimation
Reduce build time
Disable LTO by default
Disable code generation unit restriction
Allow incremental builds for the release profile
Inline various functions
Remove large stack allocations
Split large modules into multiple submodules
Add an unstable channel API feature
Prompt if the output file would be overwritten and add -y to override it.
benwaggoner
15th January 2021, 19:27
Looks to be a solid release that lays some good foundations for future work. Still, kind of less that I'd expect after 11 months for this new an encoder. It got hit by the Mozilla layoffs IIRC.
Are they going to merge in the SVT-AV1 work that the AOM encoder is now basing itself on?
foxyshadis
18th January 2021, 11:53
Looks to be a solid release that lays some good foundations for future work. Still, kind of less that I'd expect after 11 months for this new an encoder. It got hit by the Mozilla layoffs IIRC.
Are they going to merge in the SVT-AV1 work that the AOM encoder is now basing itself on?
There's been some cross-pollination, but as far as I've seen there's no public attempt to unify anything, so it's kind of ending up in the typical Google mode of having multiple overlapping things, none of which do all the things, and with no idea of what will be axed first.
hajj_3
15th February 2021, 10:31
https://github.com/xiph/rav1e/releases/tag/v0.5.0-alpha
hajj_3
31st October 2021, 22:49
https://github.com/xiph/rav1e/releases/tag/v0.5.0
johnsonlam
21st December 2021, 04:40
Thanks for updating, I'm starting to convert some of the video with AV1.
mzso
30th December 2021, 18:57
Hi!
Is it better than libaom these days?
Gravitator
12th January 2022, 14:20
Hi!
Is it better than libaom these days?
It is strongly discouraged to use in high-speed encoding modes (disgusting picture quality).
benwaggoner
12th January 2022, 18:29
It is strongly discouraged to use in high-speed encoding modes (disgusting picture quality).
How about for slower, higher quality encoding? Do you mean there are scenarios where libaom offers better quality @ perf?
Gravitator
12th January 2022, 19:54
How about for slower, higher quality encoding? Do you mean there are scenarios where libaom offers better quality @ perf?
AOM gives higher quality on fast modes. Rav1e - smeared and eye-scratching ringing.
ffmpeg -i c:\Park.mkv -c:v libaom-av1 -pix_fmt yuv420p -b:v 2.2M -cpu-used 8 c:\AOM.mkv
ffmpeg -i c:\Park.mkv -c:v librav1e -b:v 3.2M -speed 10 c:\RAV1E.mkv
Source > Park.mkv (https://files.videohelp.com/u/227452/Park.mkv)
benwaggoner
13th January 2022, 03:30
AOM gives higher quality on fast modes. Rav1e - smeared and eye-scratching ringing.
ffmpeg -i c:\Park.mkv -c:v libaom-av1 -pix_fmt yuv420p -b:v 2.2M -cpu-used 8 c:\AOM.mkv
ffmpeg -i c:\Park.mkv -c:v librav1e -b:v 3.2M -speed 10 c:\RAV1E.mkv
Source > Park.mkv (https://files.videohelp.com/u/227452/Park.mkv)
Is that comparison at the same speed levels, or the same real-world speed with a lot of cores available?
Gravitator
13th January 2022, 05:26
Is that comparison at the same speed levels, or the same real-world speed with a lot of cores available?
Adjust the AOM speed via -threads 1 (Should be close to the partner).
Gravitator
13th January 2022, 05:41
On my system RAV1E runs at 25% with any -threads values?
Audionut
22nd January 2022, 14:07
On my system RAV1E runs at 25% with any -threads values?
Play with the tiles values instead.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.