12:23
swscale/output: fix bilinear yuv2rgb chroma interpolation These functions were divided into two special cases; one assuming that uvalpha == 0, and the other assuming that uvalpha == 2048. This worked fine for simple 2x chroma upscaling but broke for e.g. yuv410p, non-centered chroma, or other special cases that involved non-aligned chroma filters. Fix it by instead dividing this check into two cases, a uvalpha==0 fast path and a uvalpha>0 general path. Instead of (A+B)/2 the general path now multiplies in the true uvalpha weight. I tried preserving the old fast path for the case of (...)
04:03
lavc/riscv: vset macro for simplify if-else [DH] libavcodec/riscv/h26x/asm.S
12:59
tests/swscale: allow nonzero positive return codes from sws_scale_frame() See previous commit. Signed-off-by: Niklas Haas <gitⓐhaasn.dev> Sponsored-by: Sovereign Tech Fund [DH] libswscale/tests/swscale.c
12:57
swscale: fix documentation of sws_scale_frame() Since its introduction, this function has claimed to return 0 on success, yet never actually did so (until the introduction of the new graph based API). It always returned the number of scaled lines, and continues to do so. To avoid confusion, but also avoid regressing possible clients that relied on the existing semantics, simply update the documentation to reflect the actual behavior. Remain ambiguous about the exact interpretation of the return value on account of the unfortunate difference in behavior between the legacy and new scaling (...)
12:47
avutil/mem_internal: Don't include stdalign.h on MSVC It's currently actually not used in MSVC builds, since 6e49b8699657b808b7dc80033f2c3f2d0e029fa3. Older versions of MSVC (or, in particular, older versions of UCRT) don't have stdalign.h; it's available since WinSDK 10.0.20348.0; such a new enough version has been installed by default only since MSVC 2022 17.4 and newer. With this change, ffmpeg can still be built with MSVC 2019 16.8 (v19.28). Signed-off-by: Martin Storsjö <martinⓐmartin.st> [DH] (...)
12:45
aarch64: vvc: Fix building the dmvr_hv assembly with older MSVC versions Explicitly use ldur for unaligned offsets; newer versions of armasm64 implicitly convert ldr to ldur as necessary, but older versions require it explicitly written out. This fixes these build errors: ffmpeg\\libavcodec\\aarch64\\vvc\\inter.o.asm(2039) : error A2518: operand 2: Memory offset must be aligned ldr s5, [x1, #1] ffmpeg\\libavcodec\\aarch64\\vvc\\inter.o.asm(2250) : error A2518: operand 2: Memory offset must be aligned ldr d7, [x1, #2] Signed-off-by: Martin Storsjö <martinⓐmartin.st> [DH] (...)
06:55
avutil/vulkan_glslang: Fix build failure compile_only isn't available until 13.1.0. Let default initialization set it to zero, so the code works with version before and after 13.1.0. [DH] libavutil/vulkan_glslang.c