From baab06157ba336da2b883940384e0ae3e784c26d Mon Sep 17 00:00:00 2001 From: "riseproject-dev[bot]" <330740410+riseproject-dev[bot]@users.noreply.github.com> Date: Thu, 1 Oct 2026 08:34:38 +0000 Subject: [PATCH 1/3] torchcodec: Add version 0.17.0 Signed-off-by: riseproject-dev[bot] <330740410+riseproject-dev[bot]@users.noreply.github.com> --- docs/packages/torchcodec.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/packages/torchcodec.yaml b/docs/packages/torchcodec.yaml index 35798da9d59..965ed1c5376 100644 --- a/docs/packages/torchcodec.yaml +++ b/docs/packages/torchcodec.yaml @@ -19,3 +19,4 @@ versions: - filename: torchcodec-0.16.0-cp314-cp314t-manylinux_2_39_riscv64.whl sha256: ec2737c8c840effbdfd0199774964969465f75e73b9afd4e8c59f754559208e7 requires-python: '>=3.10' +- version: 0.17.0 From 447dde45025d4a236577110060b7508000257f53 Mon Sep 17 00:00:00 2001 From: Ludovic Henry Date: Fri, 9 Oct 2026 16:31:19 +0000 Subject: [PATCH 2/3] torchcodec: carry forward riscv64 patches to 0.17.0 Nightly version bump omitted the patches/torchcodec/ directory for 0.17.0, so the build's unconditional `git apply .../*.patch` step failed with "No such file or directory" before any build/test ran. Copied forward the same patch set from 0.16.0 (unchanged since then). --- ...e-licence-texts-of-the-bundled-image.patch | 49 +++++++++++++++ ...he-no-libavif-stub-the-declared-sign.patch | 63 +++++++++++++++++++ 2 files changed, 112 insertions(+) create mode 100644 patches/torchcodec/0.17.0/0001-pyproject-glob-the-licence-texts-of-the-bundled-image.patch create mode 100644 patches/torchcodec/0.17.0/0002-DecodeAvif-give-the-no-libavif-stub-the-declared-sign.patch diff --git a/patches/torchcodec/0.17.0/0001-pyproject-glob-the-licence-texts-of-the-bundled-image.patch b/patches/torchcodec/0.17.0/0001-pyproject-glob-the-licence-texts-of-the-bundled-image.patch new file mode 100644 index 00000000000..ebd81722fe0 --- /dev/null +++ b/patches/torchcodec/0.17.0/0001-pyproject-glob-the-licence-texts-of-the-bundled-image.patch @@ -0,0 +1,49 @@ +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 +From: Ludovic Henry +Date: Fri, 19 Sep 2026 12:00:00 +0200 +Subject: [PATCH] pyproject: glob the licence texts of the bundled image codecs + +Upstream-Status: Inappropriate [our wheels are repaired by cibuildwheel's auditwheel, not by upstream's packaging/repair_wheel.py] + +torchcodec redistributes libjpeg-turbo, libpng, zlib and libwebp as +binaries inside the wheel, and their (permissive) licences require the +copyright notice to travel with the binary. Upstream satisfies that in +packaging/repair_wheel.py's bundle_third_party_licenses(), which unpacks +each freshly built wheel, copies the licence texts out of the conda +packages the libraries came from into .dist-info/licenses/third_party/, +and repacks. That path is unusable here for two independent reasons: it +resolves the texts through CONDA_PREFIX/conda-meta (there is no conda +environment in the manylinux image, the libraries come from Rocky rpms), +and it hardcodes dist/ -> dist_repaired/ plus a mandatory S3 libavif +directory, neither of which exists under cibuildwheel's own auditwheel +repair step. + +So the texts are staged next to the project's own LICENSE instead, as +LICENSE.., and picked up by widening the PEP 639 +license-files list. An explicit license-files list has no default glob +behind it, so without this the added files are silently dropped and the +wheel ships only torchcodec's own BSD text. + +Not riscv64-specific in substance, but it only makes sense for a build +that repairs wheels with plain auditwheel, so there is nothing to send +upstream. +--- + pyproject.toml | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/pyproject.toml b/pyproject.toml +index 4a52430..fde71b9 100644 +--- a/pyproject.toml ++++ b/pyproject.toml +@@ -3,7 +3,7 @@ name = "torchcodec" + description = "A video decoder for PyTorch" + readme = "README.md" + requires-python = ">=3.10" +-license-files = ["LICENSE"] ++license-files = ["LICENSE", "LICENSE.*"] + authors = [ + { name = "PyTorch Team", email = "packages@pytorch.org" }, + ] +-- +2.51.0 + diff --git a/patches/torchcodec/0.17.0/0002-DecodeAvif-give-the-no-libavif-stub-the-declared-sign.patch b/patches/torchcodec/0.17.0/0002-DecodeAvif-give-the-no-libavif-stub-the-declared-sign.patch new file mode 100644 index 00000000000..06515ff695d --- /dev/null +++ b/patches/torchcodec/0.17.0/0002-DecodeAvif-give-the-no-libavif-stub-the-declared-sign.patch @@ -0,0 +1,63 @@ +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 +From: Ludovic Henry +Date: Sat, 19 Sep 2026 19:40:00 +0200 +Subject: [PATCH] DecodeAvif: give the no-libavif stub the declared signature + +Upstream-Status: To upstream [not yet submitted; upstream never builds this path - their wheels always link the libavif they fetch from S3, and no CI job sets TORCHCODEC_BUILD_AVIF=0] + +decode_avif() is declared in DecodeAvif.h - and defined by the +TORCHCODEC_ENABLE_AVIF branch of DecodeAvif.cpp - with four parameters +(input, mode, output_dtype, num_threads), and image_custom_ops.cpp takes +its address with TORCH_BOX(&decode_avif) to register the +"decode_avif(Tensor input, int mode, int output_dtype=0, int +num_threads=1) -> Tensor" op. The !TORCHCODEC_ENABLE_AVIF stub, however, +still has the three-parameter signature from before num_threads was +added, so it defines a *different* overload and the four-parameter one is +never defined anywhere. + +An ELF shared object may carry undefined symbols, so nothing complains: +libtorchcodec_image.so links, the wheel builds, auditwheel repairs it, +and the first torch.ops.load_library() of it fails with + + OSError: .../torchcodec/libtorchcodec_image.so: undefined symbol: + _ZN8facebook10torchcodec11decode_avifERKN5torch6stable6TensorElll + +i.e. facebook::torchcodec::decode_avif(torch::stable::Tensor const&, +long, long, long). Because load_image_library() runs at +`import torchcodec`, every entry point of the package is dead, not just +decode_avif - which defeats the documented purpose of the build flag +("A codec set to OFF is not built; its decode_*() then raises an +actionable error at call time [...] while importing torchcodec still +works"). + +Add the missing num_threads parameter to the stub. Nothing else changes: +the stub still just raises the actionable "not compiled with libavif +support" error, which is what test/utils.py's avif_is_available() looks +for to skip the AVIF tests. + +This is not riscv64-specific - any build with TORCHCODEC_BUILD_AVIF=0 or +TORCHCODEC_BUILD_IMAGE=0 produces an unloadable image library - but it is +what our wheels hit, since libavif comes from upstream's S3 bucket, which +has no riscv64 build, and neither Rocky 10 nor a riscv64 EPEL packages it. + +Signed-off-by: Ludovic Henry +--- + src/torchcodec/_core/DecodeAvif.cpp | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/src/torchcodec/_core/DecodeAvif.cpp b/src/torchcodec/_core/DecodeAvif.cpp +index 17fd03a..b40b9b9 100644 +--- a/src/torchcodec/_core/DecodeAvif.cpp ++++ b/src/torchcodec/_core/DecodeAvif.cpp +@@ -19,7 +19,8 @@ namespace facebook::torchcodec { + torch::stable::Tensor decode_avif( + [[maybe_unused]] const torch::stable::Tensor& input, + [[maybe_unused]] int64_t mode, +- [[maybe_unused]] int64_t output_dtype) { ++ [[maybe_unused]] int64_t output_dtype, ++ [[maybe_unused]] int64_t num_threads) { + STD_TORCH_CHECK( + false, + "decode_avif: torchcodec was not compiled with libavif support. Rebuild " +-- +2.51.0 From 217d350377fa30eb743a30f17de021261792edc6 Mon Sep 17 00:00:00 2001 From: Ludovic Henry Date: Sat, 10 Oct 2026 07:45:28 +0000 Subject: [PATCH 3/3] torchcodec: drop the decode_avif stub patch for 0.17.0 Upstream fixed the !TORCHCODEC_ENABLE_AVIF stub's missing num_threads parameter in pytorch/torchcodec#1671 (60db9be7), released in v0.17.0, and the result is byte-identical to what our 0002 patch produced (DecodeAvif.cpp blob b40b9b97). The carried-forward copy therefore no longer applies and has nothing left to change; 0.16.0 keeps it. --- ...he-no-libavif-stub-the-declared-sign.patch | 63 ------------------- 1 file changed, 63 deletions(-) delete mode 100644 patches/torchcodec/0.17.0/0002-DecodeAvif-give-the-no-libavif-stub-the-declared-sign.patch diff --git a/patches/torchcodec/0.17.0/0002-DecodeAvif-give-the-no-libavif-stub-the-declared-sign.patch b/patches/torchcodec/0.17.0/0002-DecodeAvif-give-the-no-libavif-stub-the-declared-sign.patch deleted file mode 100644 index 06515ff695d..00000000000 --- a/patches/torchcodec/0.17.0/0002-DecodeAvif-give-the-no-libavif-stub-the-declared-sign.patch +++ /dev/null @@ -1,63 +0,0 @@ -From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 -From: Ludovic Henry -Date: Sat, 19 Sep 2026 19:40:00 +0200 -Subject: [PATCH] DecodeAvif: give the no-libavif stub the declared signature - -Upstream-Status: To upstream [not yet submitted; upstream never builds this path - their wheels always link the libavif they fetch from S3, and no CI job sets TORCHCODEC_BUILD_AVIF=0] - -decode_avif() is declared in DecodeAvif.h - and defined by the -TORCHCODEC_ENABLE_AVIF branch of DecodeAvif.cpp - with four parameters -(input, mode, output_dtype, num_threads), and image_custom_ops.cpp takes -its address with TORCH_BOX(&decode_avif) to register the -"decode_avif(Tensor input, int mode, int output_dtype=0, int -num_threads=1) -> Tensor" op. The !TORCHCODEC_ENABLE_AVIF stub, however, -still has the three-parameter signature from before num_threads was -added, so it defines a *different* overload and the four-parameter one is -never defined anywhere. - -An ELF shared object may carry undefined symbols, so nothing complains: -libtorchcodec_image.so links, the wheel builds, auditwheel repairs it, -and the first torch.ops.load_library() of it fails with - - OSError: .../torchcodec/libtorchcodec_image.so: undefined symbol: - _ZN8facebook10torchcodec11decode_avifERKN5torch6stable6TensorElll - -i.e. facebook::torchcodec::decode_avif(torch::stable::Tensor const&, -long, long, long). Because load_image_library() runs at -`import torchcodec`, every entry point of the package is dead, not just -decode_avif - which defeats the documented purpose of the build flag -("A codec set to OFF is not built; its decode_*() then raises an -actionable error at call time [...] while importing torchcodec still -works"). - -Add the missing num_threads parameter to the stub. Nothing else changes: -the stub still just raises the actionable "not compiled with libavif -support" error, which is what test/utils.py's avif_is_available() looks -for to skip the AVIF tests. - -This is not riscv64-specific - any build with TORCHCODEC_BUILD_AVIF=0 or -TORCHCODEC_BUILD_IMAGE=0 produces an unloadable image library - but it is -what our wheels hit, since libavif comes from upstream's S3 bucket, which -has no riscv64 build, and neither Rocky 10 nor a riscv64 EPEL packages it. - -Signed-off-by: Ludovic Henry ---- - src/torchcodec/_core/DecodeAvif.cpp | 3 ++- - 1 file changed, 2 insertions(+), 1 deletion(-) - -diff --git a/src/torchcodec/_core/DecodeAvif.cpp b/src/torchcodec/_core/DecodeAvif.cpp -index 17fd03a..b40b9b9 100644 ---- a/src/torchcodec/_core/DecodeAvif.cpp -+++ b/src/torchcodec/_core/DecodeAvif.cpp -@@ -19,7 +19,8 @@ namespace facebook::torchcodec { - torch::stable::Tensor decode_avif( - [[maybe_unused]] const torch::stable::Tensor& input, - [[maybe_unused]] int64_t mode, -- [[maybe_unused]] int64_t output_dtype) { -+ [[maybe_unused]] int64_t output_dtype, -+ [[maybe_unused]] int64_t num_threads) { - STD_TORCH_CHECK( - false, - "decode_avif: torchcodec was not compiled with libavif support. Rebuild " --- -2.51.0