torchcodec: Add version 0.16.0

[luhenry]

• Package: torchcodec
• Version: 0.16.0
• Source: https://github.com/pytorch/torchcodec
• Docs: https://pytorch.org/torchcodec/stable/index.html

Compiles PyTorch's video decoder: a C++20 core linked against libtorch and FFmpeg, plus a separate FFmpeg-free image-decoder library. Upstream publishes no riscv64 wheel.

Mirrors upstream's linux_wheel.yaml.

Differs from upstream

• FFmpeg built from source in the container - upstream's prebuilt non-GPL tarballs have no riscv64 build.
• FFmpeg 6.1, so the single libtorchcodec_core6.so matches ubuntu-24.04-riscv's system FFmpeg.
• TORCHCODEC_BUILD_AVIF=0, TORCHCODEC_BUILD_HEIC=0 - libavif comes from the same bucket, libheif is in neither Rocky 10 nor a riscv64 EPEL.
• Warnings-as-errors off - untested compiler/arch combination.

Testing

• torchvision not on the registry, so test_transform_ops.py is deselected.
• Slow tests skipped (the suite's own default) rather than force-enabled as upstream's CI does.
• The encoder tests that need a codec this FFmpeg does not have are deselected - see Second CI run below for why, and for what stays covered.

License: Wheel bundles libjpeg-turbo, libpng, zlib and libwebp (all permissive); upstream ships their licence texts from its own repair script, which this build does not use, so the build adds them.

Patches

• 0001-pyproject-glob-the-licence-texts-of-the-bundled-image.patch - Upstream-Status: Inappropriate. Without it PEP 639's explicit license-files list silently drops the vendored-library licence texts. Not riscv64-specific, but only meaningful for a plain-auditwheel repair.
• 0002-DecodeAvif-give-the-no-libavif-stub-the-declared-sign.patch - Upstream-Status: To upstream. DecodeAvif.cpp's !TORCHCODEC_ENABLE_AVIF stub still has the three-parameter signature from before num_threads was added, so with TORCHCODEC_BUILD_AVIF=0 the four-parameter decode_avif() that DecodeAvif.h declares and image_custom_ops.cpp registers via TORCH_BOX(&decode_avif) is defined nowhere. An ELF shared object may carry undefined symbols, so everything stays green until the first dlopen - which load_image_library() performs at import torchcodec, taking the whole package down. Not riscv64-specific; upstream never builds this path because their wheels always link the libavif they fetch from S3.

First CI run (all four jobs failed at the test step)

OSError: Could not load this library: .../torchcodec/libtorchcodec_image.so

pytest's conftest import report drops the exception chain, so the cause was not in the log. Reproduced under docker+QEMU against quay.io/pypa/manylinux_2_39_riscv64, which gives it:

OSError: .../libtorchcodec_image.so: undefined symbol:
  _ZN8facebook10torchcodec11decode_avifERKN5torch6stable6TensorElll

Patch 0002 is the fix.

Second CI run: the wheel builds and imports everywhere, and 242 tests need an encoder that does not exist here

All four interpreters got past patch 0002 - the wheel builds, repairs and imports - and then failed the same 242 tests each (242 failed, ~1515 passed, ~863 skipped; cp312/cp313/cp314/cp314t agree test-for-test). One cause, not three:

RuntimeError: validate_pixel_format, CpuDeviceInterface.cpp:43, Specified pixel format yuv444p is not supported by the mpeg4 encoder.
RuntimeError: initialize_video_stream, Encoder.cpp:427, Video codec av1 not found. To see available codecs, run: ffmpeg -encoders
RuntimeError: initialize_video_stream, Encoder.cpp:500, avcodec_open2 failed: Invalid argument
RuntimeError: initialize_audio_stream, Encoder.cpp:530, Codec not found
subprocess.CalledProcessError: Command '['ffmpeg', ..., 'ffmpeg_output.mp3']' returned non-zero exit status 8.

Every modern video encoder, and the MP3 one, lives in an external FFmpeg library, and this build takes none of them: ./configure --disable-static --enable-shared --enable-pic --disable-doc reports External libraries: iconv libxcb* zlib and defines no CONFIG_*_ENCODER for H.264, HEVC, VP9, AV1 or MP3 (verified by running that exact configure on FFmpeg 6.1.6 - the codec set is architecture-independent). FFmpeg then falls back to the container format's default codec, which is why the failures accuse mpeg4 of not taking yuv444p and avcodec_open2 of rejecting crf/preset/profile, rather than saying "no H.264 encoder". test_get_frame_at_av1 is the decode-side face of the same thing: FFmpeg 6.1's native AV1 decoder only runs through a hardware accelerator (libavcodec/av1dec.c: "Your platform doesn't suppport hardware accelerated AV1 decoding"), software AV1 decoding means libdav1d or libaom.

Upstream never sees this because its test job does conda install ffmpeg -c conda-forge (packaging/install_ffmpeg.sh), whose default build is the GPL one - hence test ids like test_codec_spec_vs_impl_equivalence[h264-libx264-to_file]. Two of the missing libraries, libx264 and libx265, can only be enabled with --enable-gpl, which is exactly what a wheel that links FFmpeg must not be built against, so this surface is not fixable here: it is deselected instead.

What is dropped, and what deliberately is not:

• The tests that mux a real video, shell out to the ffmpeg CLI, or ask for MP3.
• smoke_test.py entirely - every fixture it decodes is built by encoding H.264 yuv444p first, which is why its TestVideoDecoder cases are in the failure list at all.
• test_logging.py entirely - it asserts an empty subprocess stderr, which torch's libcpuinfo pollutes on this runner by reading core_id -1 from /sys (Error in cpuinfo: failed to parse file /sys/devices/system/cpu/cpu0/topology/core_id). Unrelated to FFmpeg, and not something the wheel can fix.
• Kept: the MP3 clauses are guarded (not ((test_audio_against_cli or ...) and mp3)), so the WAV and FLAC parametrisations of those same tests still run - the audio encoder, the image encoder (TestImageEncoders, PNG round-trip and the PIL comparison), the multi-stream encoder's error paths and every decoder module stay covered.

The shipped wheel bundles no FFmpeg, so none of this reaches users: on ubuntu-24.04-riscv the system FFmpeg supplies libx264, libvpx, libaom and dav1d, and encoding works there. The limitation is the container's, not the wheel's.

Local validation

• First fix (docker + binfmt QEMU, quay.io/pypa/manylinux_2_39_riscv64, cp312): the unpatched build reproduces the CI traceback exactly; with 0002 the repaired wheel imports (IMPORT_OK 0.16.0 6), ldd -r reports no unresolved symbol in any of the five shipped libraries (only the Py* ones the interpreter provides), and the workflow's own wheel-contents check passes - libtorchcodec_{core6,custom_ops6,heic,image,pybind_ops}.so plus grafted libjpeg/libpng16/libwebp/libwebpdemux/libsharpyuv, no FFmpeg and no libtorch, and the three third-party licence texts in .dist-info/licenses/.
• Second fix: FFmpeg 6.1.6 configured with the workflow's exact line in a manylinux container to confirm the codec set above. The test selection was then checked without spending a runner cycle: the 242 failing node ids were regenerated as a throwaway pytest tree (matching ids character for character, plus known-passing ids), and the CIBW_TEST_COMMAND was read back out of the YAML and executed through sh -c the way cibuildwheel invokes it. It deselects exactly the 232 in-scope failures (the other 10 are the two ignored modules) and no test that passed.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-09-20 08:08 UTC