Windows Arm64 native support: FFmpeg/libavif builders (hardware-verified on windows-11-arm) - #1673
Open
yeelam-gordon wants to merge 7 commits into
Open
Windows Arm64 native support: FFmpeg/libavif builders (hardware-verified on windows-11-arm)#1673yeelam-gordon wants to merge 7 commits into
yeelam-gordon wants to merge 7 commits into
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/meta-pytorch/torchcodec/1673
Note: Links to docs will display an error until the docs builds have been completed. This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
Hi @yeelam-gordon! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
yeelam-gordon
marked this pull request as ready for review
August 28, 2026 10:09
…ified) Adds native Windows Arm64 support for torchcodec's FFmpeg (LGPL, decode/encode) and libavif (decode-only) build dependencies, using MSYS2's CLANGARM64 subsystem (native aarch64 clang toolchain) instead of MINGW64, since mingw-w64-x86_64-toolchain only ever targets x86_64. Real hardware verification: dispatched on GitHub's free, GA windows-11-arm hosted runners via a personal fork before opening this PR. Found and fixed 3 real bugs invisible to static review, all reflected in this squashed diff: 1. `uname -m` misreports architecture under any MSYS2 shell (including CLANGARM64) -- it reports MSYS2's own POSIX runtime DLL architecture, not the MSYSTEM target toolchain -- so build_libavif.sh wrongly assumed nasm was required on aarch64 and failed. Fixed by checking $MSYSTEM first. 2. FFmpeg's ./configure hardcodes cc_default="gcc" and does not read $CC/$CXX from the environment. MSYS2's CLANGARM64 toolchain only ships clang, so configure failed with "gcc is unable to create an executable file". Fixed by passing --cc=clang --cxx=clang++ explicitly when MSYSTEM=CLANGARM64. 3. Routing the Arm64 FFmpeg build through vcvarsall.bat (as the x64 build does) sets INCLUDE/LIB to MSVC/Windows-SDK header paths. Real clang.exe (unlike gcc, which ignores %INCLUDE%) picks these up, mixing MSVC's UCRT stdlib.h with MSYS2's own mingw-w64 sysroot headers and failing to parse. Fixed by dropping the vcvarsall/vc_env_helper_arm64.bat call entirely for these two builders, matching the pattern that was already working for the (already-existing, unmodified by this PR) x64 builders. Final state: all real-hardware jobs green. - libavif-Windows-arm64 (1.4.2): https://github.com/yeelam-gordon/torchcodec/actions/runs/33155924716/job/98798560046 - LGPL-Windows-arm64, all 6 FFmpeg versions (4.4.4-9.0): https://github.com/yeelam-gordon/torchcodec/actions/runs/33157581997 - Re-verified green after a 2-round Copilot code review pass (13 findings, all addressed): https://github.com/yeelam-gordon/torchcodec/actions/runs/33166902313 and https://github.com/yeelam-gordon/torchcodec/actions/runs/33166905275 Scope: this adds only the two dependency-builder CI jobs. It does not yet add a Windows Arm64 wheel-build job for torchcodec itself (see PR description for the full list of remaining gaps). vc_env_helper_arm64.bat is included but not yet invoked by any job in this PR; it initializes the MSVC Arm64 toolchain (vcvarsall.bat arm64) and is reserved for a future torchcodec Arm64 wheel-build job that will need cl.exe/link.exe on PATH, once that job's own dependency-artifact-sourcing question (S3 publish vs. inline build) is resolved separately.
yeelam-gordon
force-pushed
the
winarm64-hackathon
branch
from
September 1, 2026 05:32
e6b715e to
6d217f2
Compare
…ripts - Fail fast (|| exit /b 1) after choco install / pacman / build_*.sh in build_ffmpeg_arm64.bat and build_libavif_arm64.bat - Replace vc_env_helper_arm64.bat's manual %1-shift argument reconstruction (which drops quoting) with %* passthrough
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
meta-cla
Bot
added
the
CLA Signed
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds native Windows Arm64 CI support for torchcodec's FFmpeg (LGPL, decode/encode) and libavif (decode-only) build dependencies, using MSYS2's CLANGARM64 (native aarch64 clang) toolchain. Squashed to a single commit containing only the files necessary for these two builder jobs to work.
Real hardware verification
Dispatched on GitHub's free, GA
windows-11-armhosted runners via a personal fork (not upstream) before opening this PR. Found and fixed 3 real bugs invisible to static review:uname -mmisreports architecture under any MSYS2 shell -> wrongnasmrequirement.configurehardcodesgcc, ignores$CC/$CXX-> needs explicit--cc=clang --cxx=clang++.vcvarsall.bat-set INCLUDE/LIB leak MSVC UCRT headers into clang's include path, breaking compile -> drop thevc_env_helper_arm64.batcall for these two builders.Final state: all real-hardware jobs green.
Scope / what this does NOT yet do
This PR only adds the dependency builders (necessary, minimal file set). It intentionally does not (and should not be read to) mean torchcodec has a full Windows Arm64 wheel yet. Still missing, as necessary follow-up (tracked separately, not part of this PR):
win_arm64entry inwindows_wheel.yaml's build matrix (upstreampytorch/test-infra'sgenerate_binary_build_matrix.ymlonly emits an x64 Windows matrix today).vc_env_helper_arm64.batis included in this PR (it initializes the MSVC Arm64 toolchain) but is deliberately not invoked by any job here -- it's reserved for that future wheel job.libheifresolution forwin-arm64(not yet published on conda-forge for this platform) or an explicitFAIL_WITHOUT_HEIC=0carve-out.install-and-testinwindows_wheel.yamlonly runs onwindows-latest/x64).Happy to open a tracking issue for the wheel-job follow-up if useful, and/or follow up with that work as a separate PR once it's proven on real hardware.
Test plan
Real windows-11-arm CI runs linked above, on my fork, prior to opening this PR.