Builder ffmpegsos-solaris10-sparc Build #13440

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpegsos-solaris10-sparc' triggered this build

Steps and Logfiles:

1. git update ( 8 secs )
   1. stdio
2. shell 'gsed -i ...' ( 0 secs )
   1. stdio
3. shell_1 'gsed -i ...' ( 0 secs )
   1. stdio
4. shell_2 'gsed -i ...' failed ( 0 secs )
   1. stdio
5. shell_3 './configure --samples="../../../ffmpeg/fate-suite" ...' failed ( 10 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 5 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config_sos.sh' failed ( 2 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. DROOdotFOO

   drewohnoyoudont@axol.io

Timing:

All Changes:

:

1. Change #268051

   Category	ffmpeg
   Changed by	DROOdotFOO <drewohnoyoudont@axol.io>
   Changed at	Fri 22 May 2026 12:03:07
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	34501921fdc38366930ac2eb3b0c4d2a615af6bb

   Comments

   tests/checkasm/sw_yuv2rgb: cover nv12 and nv21
   The previous chroma stride formula (width >> log2_chroma_w) is correct
   for planar yuv but wrong for semi-planar nv12/nv21, where the UV plane
   is interleaved at width bytes per row (width/2 UV pairs of 2 bytes
   each). Use av_image_get_linesize() so the test feeds a valid stride to
   libswscale regardless of input format; for the existing planar suites
   the value is unchanged.
   
   With the stride fixed, add nv12 and nv21 to check_yuv2rgb() so the
   upcoming NEON 16bpp paths get bench coverage. ff_get_unscaled_swscale
   does not wire a C yuv2rgb fast path for these inputs, so the suites
   report bench-only (no correctness reference); they still run clobber
   detection and cycle counts.
   
   Signed-off-by: DROOdotFOO <drew@axol.io>

   Changed files

   • tests/checkasm/sw_yuv2rgb.c

2. Change #268052

   Category	ffmpeg
   Changed by	DROOdotFOO <drewohnoyoudont@axol.io>
   Changed at	Fri 22 May 2026 12:03:07
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	2e142e52ae8b1ad36f3cca2a3ee1e53b826d20c5

   Comments

   swscale/aarch64: add NEON yuv->rgb16 fast paths
   Add NEON unscaled converters for {yuv420p, yuv422p, yuva420p, nv12, nv21}
   to {rgb565le, bgr565le, rgb555le, bgr555le}.
   
   The 16bpp packing uses v8/v9 as the output accumulator. Since AAPCS-64
   requires d8-d15 to be callee-saved, declare_func now wraps a
   stp d8, d9 / ldp d8, d9 around 16bpp paths only (gated by .ifc on the
   output format). Pattern matches libswscale/aarch64/hscale.S.
   
   yuva420p -> 16bpp drops alpha and routes through the yuv420p wrappers,
   mirroring how yuva420p -> rgb24/bgr24 already work in tree.
   
   Speedup vs C at width=1920 on Apple M1 (checkasm --bench):
   
     | input    | rgb565le | bgr565le | rgb555le | bgr555le |
     |----------|----------|----------|----------|----------|
     | yuv420p  | 3.69x    | 3.68x    | 3.28x    | 3.31x    |
     | yuv422p  | 4.70x    | 4.70x    | 4.32x    | 4.35x    |
     | yuva420p | 3.67x    | 3.66x    | 3.32x    | 3.27x    |
   
   NEON cycles are ~48 for planar and ~50.5 for semi-planar across all
   four outputs. yuv422p shows the biggest speedup because its C
   reference is the most expensive. 555 ratios trail 565 because the C
   reference is faster for 555 (one fewer mask bit); NEON cycles are the
   same. nv12/nv21 are bench-only (see the preceding checkasm commit) and
   run at the same ~50.5 cycles.
   
   This only handles the little endian forms of the 16 bit RGB formats.
   
   Verified with checkasm --test=sw_yuv2rgb (110/110) and the full
   checkasm regression (7657/7657) on Apple M1.
   
   Signed-off-by: DROOdotFOO <drew@axol.io>

   Changed files

   • libswscale/aarch64/swscale_unscaled.c
   • libswscale/aarch64/yuv2rgb_neon.S