Clean up our dav1d-rs/rav1d forks #7575
Labels
dependencies
concerning crates, pip packages etc
🧑💻 dev experience
developer experience (excluding CI)
🎞️ video
History
In the beginning there was
dav1d
; a C-library for decoding AV1 video.dav1d-rs
are bindings for the C-librarydav1d
, so one can usedav1d
from Rust.rav1d
is a Rust-port ofdav1d
. Despite being written in Rust, it does not have a Rust API (memorysafety/rav1d#1252). It only provides a C API (so it can be a drop-in replacement for dav1d`).We want to be pure Rust as far as possible, so we would prefer not to use
dav1d
, and instead userav1d
.@jprochazk put together https://github.com/rerun-io/rav1d-rs to solve this. It is a fork of BOTH
rav1d
ANDdav1d-rs
.In essence,
rav1d-rs
getsdav1d-rs
to talk torav1d
instead ofdav1d
, making the whole things pure Rust (except for some asm inrav1d
).Now, this is all very confusing, so just to iterate:
dav1d
: C library to decode AV1 (we don't want this)rav1d
: Rust library to decode AV1dav1d-rs
: Rust binding fordav1d
rav1d-rs
: Our Rust bindings forrav1d
Options
rav1d-rs
rav1d
instead (fork and upstream)Option 1: keep working on
rav1d-rs
https://github.com/rerun-io/rav1d-rs is a bit of a mess:
dav1d-rs
rav1s
source code (why? can we use the published crate instead?)dav1d-rs
andrav1d
has been modified inrav1d-rs
git lfs
and rewrite historyI'd like to:
rav1d-rs
be a clone ofdav1d-rs
ORrav1d
, but not both, as that makes diffing very hardOption 2: fork
rav1d
and add Rust bindings to itWe can fork
rav1d
and add Rust bindings to it, i.e. do:I don't know how much work this would be, but this definitely would be the nicest route (though not necessarily the easiest). We could upstream the fix, or keep using our own fork if they are not welcomed (or merged/published quick enough).
The text was updated successfully, but these errors were encountered: