x264-20250815

[Douglas R. Reno]

New dated version to go with BLFS 12.4.

[Douglas R. Reno]

commit b35605ace3ddf7c1a5d67a2eb553f034aef41d55 (HEAD -> master, origin/master, origin/HEAD)
Author: Konstantinos Margaritis <konstantinos@vectorcamp.gr>
Date:   Wed Apr 2 07:40:08 2025 +0000

    i8mm & neon hpel_filter optimization
    
    hpel_filter_c: 47995
    hpel_filter_neon: 9670
    hpel_filter_i8mm: 9643
    
    previously:
    hpel_filter_neon: 10222
    In the Neon implementation, replaced SSHR+SUB+ADD with a single SSRA

commit 291476d73386eb6f0362214f28dce058c3fff3d9
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Fri Jun 6 21:46:38 2025 +0300

    windows: Fix named pipes detection
    
    The _wstati64 call succeeds on named pipes, so to check correctly you
    must first check the result of WaitNamedPipeW.

commit 714e07b47761e694d399a5e207a9a2d8dcfdbf04
Author: Martin Storsjö <martin@martin.st>
Date:   Fri Jun 6 12:49:30 2025 +0300

    arm: Don't test x264_cpu_fast_neon_mrc_test on Windows
    
    The performance counters themselves are accessible, but the PMNC
    (control register) that we try to read to see if the performance
    counters are accessible, is not readable, causing illegal
    instructions in cpu_enable_armv7_counter.
    
    As an alternative, we could also modify cpu_fast_neon_mrc_test to
    not inspect the PMNC at all (skip calling cpu_enable_armv7_counter)
    but just assume that the counters are available, in high resolution
    mode. However just not calling this codepath is the simplest,
    as Windows on 32 bit ARM isn't very relevant these days.

commit ff620d0c3c4f717ab393892983d43458d27e4bed
Author: Coia Prant <coiaprant@gmail.com>
Date:   Tue May 27 19:44:39 2025 +0000

    configure: Use MSYSTEM_CARCH for default arch on msys2

commit 85b5ccea1fab98841d79455e344c797c5ffc3212
Author: Martin Storsjö <martin@martin.st>
Date:   Wed May 21 13:18:53 2025 +0300

    Update gas-preprocessor.pl to the latest upstream version
    
    This updates to the version from commit
    7380ac24e1cd23a5e6d76c6af083d8fc5ab9e943 from
    https://github.com/ffmpeg/gas-preprocessor.
    
    The previous version was from 2017, from commit
    ee12830747ff0b97ec6b41f4263fec63d1711365.
    
    This includes support for assembling aarch64 code with
    register ranges, such as {v0.8b-v3.8b} with armasm64 (rewritten
    into an explicit list of registers), and fixes deprecated Perl
    syntax broken by more modern versions of Perl.

commit 40617ddb88159e08c528297f2bcb85189b1c9f78
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Mon May 19 02:03:43 2025 +0300

    ci: Remove vlc-contrib dependency

commit 4360ac371073423f20d1873400e53b385c8e69c0
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date:   Mon May 19 01:28:04 2025 +0300

    ci: Fix ffmpeg build
    
    libpostproc has been removed from the ffmpeg repository.

commit 32c3b801191522961102d4bea292cdb61068d0dd
Author: Martin Storsjö <martin@martin.st>
Date:   Fri Apr 4 16:59:34 2025 +0300

    lavf: Update the code to work with the latest libavutil API

commit fe9e4a7f39d7a9fd208e4592238f9809d5936439
Author: Konstantinos Margaritis <konstantinos@vectorcamp.gr>
Date:   Tue Feb 25 11:12:19 2025 +0000

    Provide implementations for functions using the instructions SDOT/UDOT in the DotProd Armv8 extension.
    
    Functions implemented:
    sad_16x8, sad_16x16,
    sad_x3_16x8_neon, sad_x3_16x16_neon,
    sad_x4_16x8_neon, sad_x4_16x16_neon,
    ssd_8x4, ssd_8x8, ssd_8x16, ssd_16x8, ssd_16x16,
    pixel_vsad
    
    Performance improvement against Neon ranges from 5% to 188%.
    Following is the output of ./checkasm8 --bench (run on a Graviton4 system):
    
    sad_16x8_c: 1323
    sad_16x8_neon: 224
    sad_16x8_dotprod: 211
    sad_16x16_c: 2619
    sad_16x16_neon: 365
    sad_16x16_dotprod: 320
    sad_x3_16x8_c: 3836
    sad_x3_16x8_neon: 403
    sad_x3_16x8_dotprod: 317
    sad_x3_16x16_c: 7725
    sad_x3_16x16_neon: 714
    sad_x3_16x16_dotprod: 532
    sad_x4_16x8_c: 5080
    sad_x4_16x8_neon: 438
    sad_x4_16x8_dotprod: 375
    sad_x4_16x16_c: 10260
    sad_x4_16x16_neon: 794
    sad_x4_16x16_dotprod: 655
    ssd_8x4_c: 381
    ssd_8x4_neon: 157
    ssd_8x4_dotprod: 115
    ssd_8x4_sve: 150
    ssd_8x8_c: 695
    ssd_8x8_neon: 238
    ssd_8x8_dotprod: 161
    ssd_8x8_sve: 228
    ssd_8x16_c: 1335
    ssd_8x16_neon: 388
    ssd_8x16_dotprod: 267
    ssd_16x8_c: 1342
    ssd_16x8_neon: 285
    ssd_16x8_dotprod: 166
    ssd_16x16_c: 2623
    ssd_16x16_neon: 503
    ssd_16x16_dotprod: 277
    vsad_c: 2786
    vsad_neon: 311
    vsad_dotprod: 235

commit 570f6c70808287fc78e3f8f5372a095ec6ef7878
Author: Martin Storsjö <martin@martin.st>
Date:   Fri Feb 28 18:22:37 2025 +0200

    aarch64: Add runtime detection of extensions on Windows and macOS

commit 0e48d072c28b6e5283d94109391f8efbb52593f2
Author: Martin Storsjö <martin@martin.st>
Date:   Fri Feb 28 18:15:46 2025 +0200

    aarch64: Add flags for runtime detection of dotprod and i8mm
    
    Also add code for detecting them on Linux.

commit fc4012fb6788ad15e48195f2912a30ce180e9b40
Author: Martin Storsjö <martin@martin.st>
Date:   Fri Feb 28 16:07:53 2025 +0200

    configure: Check for the dotprod and i8mm aarch64 extensions

commit 87044b210a990268f4f4da9832177c5e7f9374a7
Author: Martin Storsjö <martin@martin.st>
Date:   Fri Feb 28 18:01:32 2025 +0200

    aarch64: Use configure detected directives for enabling SVE/SVE2
    
    By using .arch_extension (if supported) to enable the relevant
    extensions, we can also disable them afterwards, so we can e.g.
    cleanly enable one extension only for one subsection of a file.
    
    This also makes it easier to enable various combinations of
    supported architecture extensions.

commit f87ca1837507f06c41fcd746a14ab23ddba15a77
Author: Martin Storsjö <martin@martin.st>
Date:   Fri Feb 28 16:04:24 2025 +0200

    configure: Check for .arch and .arch_extension for enabling aarch64 extensions
    
    This hasn't been needed for SVE/SVE2, as all toolchains have
    supported just enabling it via ".arch armv8.2-a+sve". For other
    arch extensions, like dotprod/i8mm, there's more combinations of
    toolchain bugs in slightly older toolchains; try to detect what is
    supported.
    
    Additionally, when involving more than one architecture extension,
    we may want to enable/disable individual extensions one at a time,
    without needing to specify the full list in one single .arch
    statement.
    
    This is a preparatory commit for adding support for the dotprod/i8mm
    extensions.
    
    We intentionally don't add AS_ARCH_LEVEL to the CONFIG_HAVE list,
    as this define isn't prefixed with "HAVE_", and we don't use the
    define except in the case where we actually do set it. (It's not
    a regular 0/1 define like the others.)

commit 72ce1cdecf5232ad5d731f22be95b9ad3ab87a3f
Author: Martin Storsjö <martin@martin.st>
Date:   Fri Feb 28 15:42:38 2025 +0200

    configure: Use as_check for the main check for whether NEON is supported
    
    This requires adding the "-c" flag to ASFLAGS before doing the
    check.
    
    This also makes sure to validate the gas-preprocessor is functional
    for MSVC configurations, by testing whether the "cmeq" instruction
    can be assembled at this point.

commit a0191bd8b113cd35e48673bfaa3a780319640275
Author: Martin Storsjö <martin@martin.st>
Date:   Fri Feb 28 15:39:36 2025 +0200

    configure: Use as_check for checking for aarch64 features
    
    This is more correct than using cc_check; we're going to assemble
    standalone external assembly - thus check for whether we can
    build it in that form, not using inline assembly.
    
    This allows sharing checks with the MSVC codepath (where inline
    assembly isn't supported, and where assembly is built using
    a tool different from the regular compiler).

commit 27d8370847d79665de06bbf8f043ce9a3a4a3da1
Author: Martin Storsjö <martin@martin.st>
Date:   Mon Mar 3 21:44:27 2025 +0200

    Makefile: Generate dependency information implicitly while compiling
    
    This updates the dependecy information on each successive recompile.
    
    When building with MSVC, dependency information is generated with
    a separate command just like before, but done together with
    compiling each object file. (This is quite similar to how ffmpeg does
    the same.)
    
    This avoids the serial dependency generation step. In slow
    environments (in particular if using MSVC) it could take a notable
    amount of time; this can now all be done in parallel.
    
    In one example, this reduces the time for a full build from clean
    with MSVC (wrapped in wine) from 23 seconds down to 9 seconds,
    thanks to parallelism. (For non-parallel builds, it doesn't make
    much of a difference.)

commit c80f8a28151bdb2710e55da8d8fc8f6a037a6188
Author: Martin Storsjö <martin@martin.st>
Date:   Tue Mar 4 10:57:13 2025 +0200

    msvsdepend: Allow using the script for .S sources too
    
    Previously, MSVC would warn that the .S source is unrecognized,
    and the script would only produce a depenency on the main source
    file itself.

[Douglas R. Reno]

Fixed at 8fde7a5b598fd4a42cc350049805c45523b9ac9d