PoC: Port AVIF decoder from dav1d to rav1d-safe#2853
PoC: Port AVIF decoder from dav1d to rav1d-safe#2853Shnatsel wants to merge 2 commits intoimage-rs:mainfrom
Conversation
Replace the dav1d FFI-based AV1 decoder with rav1d-safe, a pure safe Rust AV1 decoder. The safe managed API simplifies the code significantly: decoder init uses a single decode() call instead of send_data/get_picture retry loops, and 16-bit plane access is type-safe (&[u16]) eliminating all the transmute/reshape helpers for FFI data. Co-Authored-By: Claude <noreply@anthropic.com>
rav1d-safe's PlaneView::as_slice() returns the full backing buffer which may be larger than stride * height. The YUV conversion code validates that plane slices are exactly stride * height. Trim the plane slices to the expected size before passing them to YuvPlanarImage. Co-Authored-By: Claude <noreply@anthropic.com>
|
The handful of samples I've thrown at it decodes fine. The default configuration (all safe code) is about 2x slower than rav1d with handwritten assembly, as advertised. This is not an entirely fair comparison since rav1d has more AVX-512 codepaths than rav1d-safe does. Here's the profile, measured with
When profiling So between the presence of the hot scalar fallback, missing AVX-512 codepaths and non-functional inline assembly for parts that couldn't be easily converted to Rust, I think there's plenty of performance still to be gained, so the gap could be closed significantly. |
1 participant
This will never be merged due to
rav1d-safebeing under the restrictive AGPL license.This PR exists purely to evaluate the performance and correctness characteristics of
rav1d-safe, and decide if trying to upstream it is worth it.Since this never going into production I had Claude Opus 4.6 do the porting, as opposed to #2849 which is entirely handwritten. This may have introduced issues, so failures of this PR should not automatically be assumed to be failures of the
rav1d-safecrate.