- Install ffnvcodec headers everywhere the project FFmpeg is built
(distro packages on Debian/Ubuntu/Arch/MSYS2, nv-codec-headers from
source on Fedora) so the FFmpeg build picks up NVDEC/NVENC.
- ocio-sys 0.2.1's vendored yaml-cpp misses <cstdint> and fails on
GCC >= 16 (measured on GCC 16.2.1); patch the dependency to the
fixed upstream tree (shaloong/ocio-rs, 933c65dc) until a fixed
release lands on crates.io.
- New tooling/ocio-env.sh decides the OCIO build env per job: system
OCIO >= 2.5 when present (static when the package ships
libOpenColorIO.a, dynamic otherwise), vendored static build as the
fallback. The Arch package gains an 'opencolorio' dependency only
when the binaries link the system OCIO (build-pkg.sh probes ldd).
- CI 'Build' steps switch from cargo build to cargo check: the Test
step links the test binaries anyway, and a full build would codegen
every workspace crate twice.
All crates take the oak-* kebab-case naming (oak-audio, oak-codec,
oak-common, oak-core, oak-ffmpeg-link, oak-node, oak-otio, oak-plugin,
oak-render, oak-storage, oak-task, oak-timeline, oak-undo), with the
lib identifiers rewritten (oakrender:: -> oak_render::, oakcore_rs:: ->
oak_core::, ...) across all 226 referencing files.
The GUI application moves from the workspace root into
crates/oak-app/: src/, build.rs (paths fixed for the new location) and
tests/ travel with it, the root Cargo.toml becomes workspace-only
([workspace] + workspace.package + profiles), and the app package
inherits the workspace version. The screenshots example becomes a
standalone crate examples/simple_player/ with its own Cargo.toml.
Every crate now inherits the single workspace version
(version.workspace = true), and the workflows' crate paths and the
build docs follow the renames.
Validated with a clean cargo check --workspace.
docs/build.md + docs/zh/build.md rewritten for the Rust workspace:
project-built FFmpeg 8.1 (.cargo/config.toml presets FFMPEG_DIR),
vendored static OCIO on Linux/macOS vs MSYS2 dynamic OCIO on Windows
(with the OCIO_INSTALL_DIR/OCIO_RS_LINK env), the Windows GNU toolchain
requirements (MSYS2 Rust, RUSTFLAGS=-C link-args=-lmsvcrt for the
mingw-w64 _assert forwarding, unset INCLUDE/LIB), Linux audio dev
packages and xvfb headless testing, container packaging, and a
troubleshooting section. The macOS-only guides gain a deprecation
pointer. Also correct two stale comments in tooling/install-deps.sh
(FFmpeg is built by tooling/ffmpeg/build-ffmpeg.sh, not by cargo).
The distro OCIO is too old for the bridge's API floor where it matters
(Ubuntu 24.04 ships 2.1; the bridge uses 2.4+ APIs), and version drift
across platforms is a support hazard — enable ocio-rs' bundled feature
and drop the OCIO_INSTALL_DIR/system-package wiring from CI and CD so
Linux, macOS and Windows all build the same vendored OCIO. cmake/make/
diffutils added where the runners lack them (Windows FFmpeg build needs
make + cmp).
- Homebrew renamed libtheora->theora and libwebp->webp; the old names
no longer resolve, failing the macOS dependency step
- retry the MSYS2 pacman install (3 attempts, --needed resumes): CI
mirrors stall mid-download ("Operation too slow") often enough to
matter
- tooling/ffmpeg/build-ffmpeg.sh builds release/8.0 static+PIC into
.cache/ffmpeg: GPL/version3, every free-license external codec lib
probed via pkg-config (enabled when present), per-OS hardware
acceleration (VideoToolbox/AudioToolbox, VAAPI/VDPAU/libdrm,
D3D11VA/DXVA2/MediaFoundation, nvenc when ffnvcodec exists)
- tooling/install-deps.sh installs those libraries on Homebrew / MSYS2
UCRT64 / Debian-Ubuntu / Fedora / Arch; nothing in the build sudo's
- ffmpeg-next's own build feature is unusable (every crate-version to
FFmpeg-release pairing is broken upstream: 9.0.0->FF9 AVCodec fields,
8.1.0->FF8.1 new enum variants, 8.0.0->FF8 FF_PROFILE rename), so
ffmpeg-next 9 + FFmpeg 8.x headers via FFMPEG_DIR it is
- new links-crate oakffmpeg-link emits the static FFmpeg's transitive
link flags from its .pc files (cargo only propagates them from links
crates, and rustc prunes the flags unless the rlib is referenced —
hence the force_link statics)
- docs/build.md updated for the Rust workspace flow
Mike-Solar