macOS x265 builds missing git tag for version detection

The macOS x265 builds (both x64 and ARM64) are missing the git tag 4.1 command that the Windows builds explicitly include for version detection. With shallow clones using --depth 1 --branch Release_4.1, the tag isn't reachable from HEAD, causing git describe --abbrev=0 --tags to fail. The Windows builds include comments explaining this workaround, but the macOS builds skip directly to cd x265_git/build without creating the local tag. This could cause version detection failures or incorrect version strings in the built x265 libraries.

Windows x265 pkg-config reports wrong version after upgrade

The PR changes Windows x265 from vcpkg installation to building version 4.1 from source (Release_4.1 branch), but the pkg-config files still report version "3.5". The macOS builds correctly set "Version: 4.1" in their pkg-config files, but the Windows builds at lines 259 and 667 were not updated. This version mismatch could cause issues for downstream consumers that check pkg-config --modversion x265 for version compatibility, such as requiring version >= 4.0 for alpha channel support.

macOS x265 builds missing git tag for version detection

The macOS x265 builds are missing the git tag 4.1 command that the Windows builds include. The Windows builds have explicit comments explaining this tag is required because git describe --abbrev=0 --tags needs a tag reachable from HEAD, and shallow clones don't include the tag in history. Without creating this local tag, x265's version detection during CMake configure may fail or produce incorrect version information.

x265 pkg-config version mismatch after source build upgrade

The Windows builds create pkg-config files with x265 version "3.5", but this PR now builds x265 version 4.1 from source (using the Release_4.1 branch). The version strings in the create_pc calls for x265 weren't updated to match the actual library version being built. This version mismatch could cause issues if consuming software performs version checks.

The pkg-config file for Windows x64 uses -lstdc++ in Libs.private, but this is incorrect for Windows with MSVC/ClangCL toolchains which use the MSVC C++ runtime instead. This could cause linking failures when FFmpeg tries to link against x265. Consider removing Libs.private on Windows or using appropriate Windows C++ runtime flags.

The cmake build commands use --parallel without specifying a job count. While this will use all available cores by default, it could cause resource exhaustion on CI runners with limited memory, especially when building multiple variants (12-bit, 10-bit, 8-bit) sequentially. Consider adding explicit job limits like --parallel 2 or using environment variables to control parallelism based on available resources.

The Windows x265 build scripts clone a repository using --depth 1 which creates a shallow clone without tags. The script then creates a local tag 4.1, but this tag is never pushed and only exists locally in the CI environment. While this works for the immediate build, it creates an inconsistency where the tag only exists in the CI runner's temporary environment and doesn't reflect the actual repository state. Consider using git fetch --depth 1 origin refs/tags/Release_4.1:refs/tags/Release_4.1 instead to fetch the actual tag, or document why a local tag is necessary if git describe is being used internally by the x265 build system.

The script copies header files with error suppression (2>/dev/null || true), which silently ignores failures. If these headers are critical for the build, the copy should fail loudly. If they're optional or already exist, this should be documented. Without proper error handling, a missing header file could cause cryptic build failures later in the FFmpeg compilation stage.

The same error suppression pattern (2>/dev/null || true) is used when copying header files in the macOS ARM64 build. This creates the same issue as in the x64 build where critical file copy failures could be silently ignored. Ensure these headers are either guaranteed to exist or handle their absence explicitly with proper error messages.

This git clone operation has the same security concern as the Windows ARM64 build. The code is cloned from a branch without commit SHA verification or integrity checks. If the x265 repository or Release_4.1 branch were compromised, malicious code could be introduced into the build. Consider verifying the cloned code's integrity or pinning to a specific verified commit SHA.

This git clone operation lacks commit SHA verification or integrity checks, similar to the Windows builds. Consider pinning to a specific verified commit SHA or adding checksum verification to ensure the cloned source code hasn't been tampered with.

The Windows x64 build has the exact same local tag creation logic as the ARM64 build. The tag is created locally but never used or pushed. This is duplicated code that adds maintenance burden. If the tag is required for x265's version detection during the build, this should be documented. Otherwise, consider removing these tag creation steps or consolidate them into a reusable script.

The pkg-config file for Windows uses -lstdc++ in Libs.private, but Windows with MSVC/ClangCL typically doesn't use libstdc++. Windows uses the MSVC C++ runtime (MSVCRT/UCRT) by default. This could cause linking issues when FFmpeg tries to use this pkg-config file. Consider removing Libs.private on Windows or using appropriate Windows C++ runtime flags if needed.

Windows pkg-config uses incompatible GCC library flag

The Windows x265 pkg-config files specify Libs.private: -lstdc++, but the builds use MSVC/ClangCL toolchain which doesn't have libstdc++. The -lstdc++ flag is a GCC/MinGW convention for the GNU C++ standard library. When FFmpeg uses pkg-config with --static, this would attempt to link a non-existent library. The macOS builds correctly use -lc++ for the Clang runtime. For MSVC, Libs.private could be empty since the C++ runtime is linked automatically, or removed entirely.

macOS builds missing git tag for version detection

The macOS x265 builds (both x64 and arm64) are missing the git tag 4.1 command that exists in the Windows builds. The Windows builds include explicit comments explaining this step is necessary because shallow clones with --depth 1 don't include tags in the history, causing git describe --abbrev=0 --tags (used by x265's CMake for version detection) to fail. Without this step, the x265 build on macOS may produce incorrect version information in x265_config.h or encounter version detection failures.

The comment states "vcpkg's x265.pc was overwritten" but this is misleading - x265 was never installed via vcpkg in this workflow (it was explicitly removed from the vcpkg install list), so there's no existing x265.pc file to overwrite. Consider updating the comment to clarify that this creates the pkg-config file since x265 is built from source instead of via vcpkg.

The comment states "vcpkg's x265.pc was overwritten" but this is misleading - x265 was never installed via vcpkg in this workflow (it was explicitly removed from the vcpkg install list), so there's no existing x265.pc file to overwrite. Consider updating the comment to clarify that this creates the pkg-config file since x265 is built from source instead of via vcpkg.

The git clone command lacks error handling. If the clone fails (e.g., network issues, repository unavailable), the subsequent commands will fail in confusing ways. Consider adding error handling or using set -e for bash scripts to fail fast on errors.

The PowerShell script lacks proper error handling via $ErrorActionPreference. If any command fails (git clone, cmake, lib.exe, Copy-Item), the script continues executing which could lead to incomplete or corrupted builds. Consider adding $ErrorActionPreference = 'Stop' at the beginning of the script block to fail fast on errors.

The git clone command lacks error handling. If the clone fails (e.g., network issues, repository unavailable), the subsequent commands will fail in confusing ways. Consider adding error handling or using $ErrorActionPreference = 'Stop' at the beginning of the script block to fail fast on errors.

The PowerShell script lacks proper error handling via $ErrorActionPreference. If any command fails (git clone, cmake, lib.exe, Copy-Item), the script continues executing which could lead to incomplete or corrupted builds. Consider adding $ErrorActionPreference = 'Stop' at the beginning of the script block to fail fast on errors.