x265/4.1 package update

[octo-sts]

[github-actions]

Package x265: Click to expand/collapse

Package x265:
Added: /usr/lib/libx265.so.215
Modified: /usr/bin/x265
Deleted: /usr/lib/libx265.so.212

Package x265-dev: Click to expand/collapse

Package x265-dev:
Modified: /usr/include/x265.h
Modified: /usr/include/x265_config.h
Modified: /usr/lib/libx265.a
Modified: /usr/lib/pkgconfig/x265.pc

[github-actions]

Package x265: Click to expand/collapse

Package x265:
Added: /usr/lib/libx265.so.215
Modified: /usr/bin/x265
Deleted: /usr/lib/libx265.so.212

Package x265-dev: Click to expand/collapse

Package x265-dev:
Modified: /usr/include/x265.h
Modified: /usr/include/x265_config.h
Modified: /usr/lib/libx265.a
Modified: /usr/lib/pkgconfig/x265.pc

[github-actions]

Package x265-dev: Click to expand/collapse

Package x265-dev:
Modified: /usr/include/x265.h
Modified: /usr/include/x265_config.h
Modified: /usr/lib/libx265.a
Modified: /usr/lib/pkgconfig/x265.pc

Package x265: Click to expand/collapse

Package x265:
Added: /usr/lib/libx265.so.215
Modified: /usr/bin/x265
Deleted: /usr/lib/libx265.so.212

[github-actions]

Package x265-dev: Click to expand/collapse

Package x265-dev:
Modified: /usr/include/x265.h
Modified: /usr/include/x265_config.h
Modified: /usr/lib/libx265.a
Modified: /usr/lib/pkgconfig/x265.pc

Package x265: Click to expand/collapse

Package x265:
Added: /usr/lib/libx265.so.215
Modified: /usr/bin/x265
Deleted: /usr/lib/libx265.so.212

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the build error output, I can provide a specific analysis and fix:

• Detected Error:

libavcodec/libx265.c:813:59: error: passing argument 5 of 'ctx->api->encoder_encode' from incompatible pointer type [-Wincompatible-pointer-types]

• Error Category: Build/Type Mismatch

• Failure Point: Compilation of libx265.c encoder integration

• Root Cause Analysis: The libx265 encoder API call has a type mismatch where it's passing a x265_picture** (double pointer) where it expects a x265_picture* (single pointer).

• Suggested Fix:
Modify libavcodec/libx265.c line 813 from:

pic ? &x265pic : NULL, x265pic_lyrptr_out);

to:

pic ? &x265pic : NULL, *x265pic_lyrptr_out);

• Explanation:
The x265 encoder API expects a single pointer for the output picture parameter, but the code is passing a double pointer. The fix dereferences the pointer to match the expected type signature. This aligns with x265's API requirements.

• Additional Notes:

• This appears to be a regression or compatibility issue with newer versions of x265
• The fix ensures type safety while maintaining the intended functionality
• After this fix, the build should proceed past this error

• References:

• x265 API documentation: https://x265.readthedocs.io/en/master/api.html
• Similar issue discussed: https://bitbucket.org/multicoreware/x265_git/issues/559/

The fix resolves the immediate type mismatch while preserving the encoder's functionality. This is a common issue when interfacing with external codec libraries that have strict type requirements.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the build error, I'll provide a structured analysis and solution:

• Detected Error:

libavcodec/libx265.c:813:59: error: passing argument 5 of 'ctx->api->encoder_encode' from incompatible pointer type [-Wincompatible-pointer-types]
813 | pic ? &x265pic : NULL, x265pic_lyrptr_out);

• Error Category: Type error - Incompatible pointer types

• Failure Point: libx265 encoder integration in FFmpeg when passing parameters to x265 encoder API

• Root Cause Analysis:
The code is passing an x265_picture** where the x265 API expects an x265_picture*. This is a type mismatch that needs to be corrected.

• Suggested Fix:
Modify the ffmpeg package yaml to specify a compatible version of x265 or patch the source. Add this patch to the pipeline:

pipeline:
  - uses: git-checkout
    with:
      repository: https://github.com/FFmpeg/FFmpeg
      expected-commit: b08d7969c550a804a59511c7b83f2dd8cc0499b8
      tag: n${{package.version}}

  - runs: |
      sed -i 's/x265pic_lyrptr_out/\*x265pic_lyrptr_out/' libavcodec/libx265.c

  - uses: autoconf/make

  - uses: autoconf/make-install

  - uses: strip

• Explanation:
The fix addresses the pointer type mismatch by dereferencing the pointer to match the expected type in the x265 API. This is a common issue when interfacing with external encoding libraries and their APIs.

• Additional Notes:

• The error appears in FFmpeg 7.1 when building against x265
• The fix ensures proper type compatibility between FFmpeg and x265
• No functionality changes, just correcting the type system requirements

• References:

• FFmpeg libx265 encoder documentation: https://ffmpeg.org/ffmpeg-codecs.html#libx265
• x265 API documentation: https://x265.readthedocs.io/en/master/api.html
• Related FFmpeg ticket: https://trac.ffmpeg.org/ticket/9405

The fix should allow the build to complete successfully while maintaining proper type safety.

[octo-sts]

Gen AI suggestions to solve the build error:

• Detected Error: "solving 'so:libicuuc.so.75' constraint: icu-75.1-r0.apk disqualified because '75.1-r0' does not satisfy 'icu=76.1-r0'"

• Error Category: Dependency

• Failure Point: Package dependency resolution during build environment setup

• Root Cause Analysis: There's a version mismatch between harfbuzz-dev (10.1.0-r0) which requires ICU 75.x, but the system is trying to use ICU 76.1. This is a binary compatibility issue with shared libraries.

• Suggested Fix:

1. Add explicit ICU version constraint in environment.contents.packages:

environment:
  contents:
    packages:
      # Update harfbuzz and related packages to versions compatible with ICU 76.1
      - harfbuzz=10.2.0-r0
      - harfbuzz-dev=10.2.0-r0
      # Or pin to specific ICU version
      - icu=75.1-r3
      - icu-libs=75.1-r3
      - icu-dev=75.1-r3

• Explanation: Harfbuzz 10.1.0 was built against ICU 75.x, while the system is trying to use ICU 76.1. By either upgrading harfbuzz to a version compatible with ICU 76.1 or pinning ICU to version 75.x, we can resolve the shared library version mismatch.

• Additional Notes:

• This is a common issue when dealing with C/C++ libraries that have strict ABI compatibility requirements
• HarfBuzz and ICU are tightly coupled due to text shaping functionality
• Always check the build requirements of HarfBuzz against the ICU version in use

• References:

• HarfBuzz dependency documentation: https://github.com/harfbuzz/harfbuzz#dependencies
• ICU ABI compatibility policy: https://icu.unicode.org/design/stability

[octo-sts]

Gen AI suggestions to solve the build error:

• Detected Error: Incompatible pointer type error in libx265.c

libavcodec/libx265.c:813:59: error: passing argument 5 of 'ctx->api->encoder_encode' from incompatible pointer type

• Error Category: Build error - Type mismatch

• Failure Point: Compilation of libx265.c encoder integration

• Root Cause Analysis: The x265 encoder API expects a x265_picture* for the 5th parameter but code is passing x265_picture**

• Suggested Fix:

// Change from:
pic ? &x265pic : NULL, x265pic_lyrptr_out

// To:
pic ? &x265pic : NULL, *x265pic_lyrptr_out 

• Explanation: The x265 encoder API function expects a pointer to x265_picture, but the code is passing a pointer to a pointer. Dereferencing the pointer with * will provide the correct type.

• Additional Notes:

• This appears to be a mismatch between the x265 API expectations and how the FFmpeg integration code is handling picture structures
• The fix ensures type compatibility while maintaining the functionality
• Similar fixes may be needed elsewhere if the same pattern is used

• References:

• x265 API documentation: https://x265.readthedocs.io/en/master/api.html#encoder-encoding
• Similar issue in FFmpeg: https://trac.ffmpeg.org/ticket/9396

To apply this fix:

1. Edit libavcodec/libx265.c
2. Find the encoder_encode call around line 813
3. Update the argument to dereference the pointer
4. Rebuild the package

This should resolve the immediate build error while preserving the encoding functionality.