Builder ffmpeg64-solaris10-i386 Build #13507

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpeg64-solaris10-i386' triggered this build

Steps and Logfiles:

1. git update ( 7 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 ( 14 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 0 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config_64.sh' failed ( 0 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Niklas Haas

   gitohnoyoudont@haasn.dev

Timing:

All Changes:

:

1. Change #262740

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sun 29 Mar 2026 12:10:38
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	915523e136a65707f0092739471bd384bfeeb999

   Comments

   swscale/ops: add missing check on SwsDitherOp.y_offset
   Doesn't actually affect anything in the currently generated ops lists.
   
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • libswscale/ops.c

2. Change #262741

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sun 29 Mar 2026 12:10:38
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	7989fd973ade991714856c0111b4b11f75e3de9c

   Comments

   swscale/ops: add min/max to SwsDitherOp
   This gives more accurate information to the range tracker.
   
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • libswscale/format.c
   • libswscale/ops.h

3. Change #262742

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sun 29 Mar 2026 12:13:11
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	f6a2d41fe2f3316b05dffdce96f867a0b9bf88cd

   Comments

   swscale/ops: keep track of correct dither min/max
   Mostly, this just affects the metadata in benign ways, e.g.:
   
    rgb24 -> yuv444p:
      [ u8 +++X] SWS_OP_READ         : 3 elem(s) packed >> 0
        min: {0, 0, 0, _}, max: {255, 255, 255, _}
      [ u8 +++X] SWS_OP_CONVERT      : u8 -> f32
        min: {0, 0, 0, _}, max: {255, 255, 255, _}
      [f32 ...X] SWS_OP_LINEAR       : matrix3+off3 [...]
        min: {16, 16, 16, _}, max: {235, 240, 240, _}
      [f32 ...X] SWS_OP_DITHER       : 16x16 matrix + {0 3 2 -1}
   -    min: {33/2, 33/2, 33/2, _}, max: {471/2, 481/2, 481/2, _}
   +    min: {16.001953, 16.001953, 16.001953, _}, max: {235.998047, 240.998047, 240.998047, _}
      [f32 +++X] SWS_OP_CONVERT      : f32 -> u8
        min: {16, 16, 16, _}, max: {235, 240, 240, _}
      [ u8 XXXX] SWS_OP_WRITE        : 3 elem(s) planar >> 0
        (X = unused, z = byteswapped, + = exact, 0 = zero)
   
   However, it surprisingly actually includes a semantic change, whenever
   converting from limited range to monob or monow:
   
    yuv444p -> monow:
      [ u8 +XXX] SWS_OP_READ         : 1 elem(s) planar >> 0
        min: {0, _, _, _}, max: {255, _, _, _}
      [ u8 +XXX] SWS_OP_CONVERT      : u8 -> f32
        min: {0, _, _, _}, max: {255, _, _, _}
      [f32 .XXX] SWS_OP_LINEAR       : luma [...]
        min: {-20/219, _, _, _}, max: {235/219, _, _, _}
      [f32 .XXX] SWS_OP_DITHER       : 16x16 matrix + {0 -1 -1 -1}
   -    min: {179/438, _, _, _}, max: {689/438, _, _, _}
   +    min: {-0.089371, _, _, _}, max: {2.071106, _, _, _}
   +  [f32 .XXX] SWS_OP_MAX          : {0 0 0 0} <= x
   +    min: {0, _, _, _}, max: {2.071106, _, _, _}
      [f32 .XXX] SWS_OP_MIN          : x <= {1 _ _ _}
   -    min: {179/438, _, _, _}, max: {1, _, _, _}
   +    min: {0, _, _, _}, max: {1, _, _, _}
      [f32 +XXX] SWS_OP_CONVERT      : f32 -> u8
        min: {0, _, _, _}, max: {1, _, _, _}
      [ u8 XXXX] SWS_OP_WRITE        : 1 elem(s) planar >> 3
        (X = unused, z = byteswapped, + = exact, 0 = zero)
   
   Note the presence of an extra SWS_OP_MAX, to correctly clamp sub-blacks
   (values below 16) to 0.0, rather than underflowing. This was previously
   undetected because the dither was modelled as adding 0.5 to every pixel value,
   but that's only true on average - not always.
   
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • libswscale/ops.c
   • tests/ref/fate/sws-ops-list

4. Change #262743

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sun 29 Mar 2026 12:13:40
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	3f397833375c8125b8d1a1b89a93671720bb08e5

   Comments

   swscale/ops_chain: simplify ff_sws_compile_op_tables() with int index
   Instead of this needlessly complicated dance of allocating on-stack copies
   of SwsOpList only to iterate with AVERROR(EAGAIN).
   
   This was originally thought to be useful for compiling multiple ops at once,
   but even that can be solved in easier ways.
   
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • libswscale/ops_backend.c
   • libswscale/ops_chain.c
   • libswscale/ops_chain.h
   • libswscale/x86/ops.c