Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Builder ffmpeg64-solaris10-i386 Build #12916

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

Projectffmpeg
Repositoryhttps://git.ffmpeg.org/ffmpeg.git
Branchmaster
Revision18edb246c80902e192c464fb9b7d6b15d9c11557
Got Revision18edb246c80902e192c464fb9b7d6b15d9c11557
Changes11 changes

BuildSlave:

unstable10x

Reason:

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

Steps and Logfiles:

  1. git update ( 6 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 ( 6 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:

NameValueSource
branch master Build
builddir /export/home/buildbot/slave/ffmpeg64-solaris10-i386 slave
buildername ffmpeg64-solaris10-i386 Builder
buildnumber 12916 Build
codebase Build
got_revision 18edb246c80902e192c464fb9b7d6b15d9c11557 Git
project ffmpeg Build
repository https://git.ffmpeg.org/ffmpeg.git Build
revision 18edb246c80902e192c464fb9b7d6b15d9c11557 Build
scheduler schedule-ffmpeg64-solaris10-i386 Scheduler
slavename unstable10x BuildSlave
workdir /export/home/buildbot/slave/ffmpeg64-solaris10-i386 slave (deprecated)

Forced Build Properties:

NameLabelValue

Responsible Users:

  1. Niklas Haas

Timing:

StartMon Dec 15 15:41:49 2025
EndMon Dec 15 15:42:03 2025
Elapsed14 secs

All Changes:

:

  1. Change #252264

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision 960cf3015e4ea8760814bb7cdad4990c21119bb5

    Comments

    swscale/ops: add explicit row offset to SwsDitherOp
    To improve decorrelation between components, we offset the dither matrix
    slightly for each component. This is currently done by adding a hard-coded
    offset of {0, 3, 2, 5} to each of the four components, respectively.
    
    However, this represents a serious challenge when re-ordering SwsDitherOp
    past a swizzle, or when splitting an SwsOpList into multiple sub-operations
    (e.g. for decoupling luma from subsampled chroma when they are independent).
    
    To fix this on a fundamental level, we have to keep track of the offset per
    channel as part of the SwsDitherOp metadata, and respect those values at
    runtime.
    
    This commit merely adds the metadata; the update to the underlying backends
    will come in a follow-up commit. The FATE change is merely due to the
    added offsets in the op list print-out.

    Changed files

    • libswscale/format.c
    • libswscale/ops.c
    • libswscale/ops.h
    • tests/checkasm/sw_ops.c
    • tests/ref/fate/sws-ops-list
  2. Change #252265

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision 58f933798fae0d2997a7ea0269c77fff0870ff24

    Comments

    swscale/ops_tmpl_float: respect specified dither matrix offsets
    Since we only need 8 bytes to store the dither matrix pointer, we actually
    still have 8 bytes left-over. That means we could either store the 8-bit
    row offset directly, or alternatively compute a 16-bit pointer offsets.
    
    I have chosen to do the former for the C backend, in the interest of
    simplicity.
    
    The one downside of this approach is that it would fail on hypothetical
    128-bit platforms; although I seriously hope that this code does not live
    long enough to see the need for 128-bit addressable memory.

    Changed files

    • libswscale/ops_tmpl_float.c
  3. Change #252266

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision d62102d679b004a9ce32dee8dcf75f8c513fd6aa

    Comments

    swscale/ops_tmpl_float: actually skip allocation for !size_log2 case
    This check was wrong; 1 << 0 = 1. The intent was to skip allocating a 1x1
    matrix by assuming it is a constant 0.5. But as written, the check never
    actually executed.
    
    This did not affect the runtime performance, nor did it leak memory; but it
    did mean we didn't hit the intended `assert`.

    Changed files

    • libswscale/ops_tmpl_float.c
  4. Change #252267

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision b1c96b99faa145495415272875943f4e1047e4aa

    Comments

    swscale/x86/ops_float: remove special case for 2x2 matrix
    This is an exceptionally unlikely (in fact, currently impossible) case to
    actually hit, and not worth micro-optimizing for. More specifically, having
    this special case prevents me from easily adding per-row offsets.

    Changed files

    • libswscale/x86/ops.c
    • libswscale/x86/ops_float.asm
  5. Change #252268

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision 0744260ff0e9e3a8832754c51c5515a0a0ce2793

    Comments

    swscale/x86/ops: over-allocate dither matrix
    I want to change the way offsets are calculated inside the dither asm;
    and the cleanest way to solve that problem is to just over-allocate the
    entire dither matrix based on the maximum offset range we expected.

    Changed files

    • libswscale/x86/ops.c
  6. Change #252269

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision 3f7e3cedb58cb963a5cb90e81b7654d993b842cf

    Comments

    swscale/x86/ops_float: store and load per row dither offset directly
    Instead of computing y + N with a hard-coded index offset, calculate the
    relative offset as a 16-bit integer in C and add that to the pointer directly.
    Since we no longer mask the resulting combined address, this may result in
    overread, but that's fine since we over-provisioned the array in the previous
    commit.

    Changed files

    • libswscale/x86/ops.c
    • libswscale/x86/ops_common.asm
    • libswscale/x86/ops_float.asm
  7. Change #252270

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision d5174f9e5b701d4f272011a93677889d31986dbe

    Comments

    swscale/format: add source format info to ff_sws_encode_colors()
    Specifically, I need access to this for generating a better dither matrix.

    Changed files

    • libswscale/format.c
    • libswscale/format.h
    • libswscale/graph.c
    • libswscale/tests/sws_ops.c
  8. Change #252271

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision 618492489278457bbf14833d57568bd04bf459f0

    Comments

    swscale/format: don't add chroma noise when dithering grayscale content
    On the surface, this trades a tiny bit of PSNR for not introducing chroma
    noise into grayscale images. However, the main reason for this change is
    actually motivated by a desire to avoid regressing the status quo of
    duplicating swizzles being able to be commuted past dither ops.

    Changed files

    • libswscale/format.c
    • tests/ref/fate/sws-ops-list
  9. Change #252272

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision 1cc4c2b236d55feec158f04b20caa1aa0e2e1a50

    Comments

    swscale/ops_optimizer: rework ambiguous op_type_is_independent()
    The current usage is ambiguous between "affects each component equally" and
    "affects each component independently" - and arguably, the current behavior
    was a bug (since SWS_OP_DITHER should not commute with a SWIZZLE, at least
    from a bit-exactness PoV).
    
    However, when trying to define cleaner replacements for these concepts, I
    realized there are too many special cases; and given that we only have two
    use sites, I decided to just split them directly into "commute" functions
    for those particular usage cases.
    
    As an added benefit, this moves the commutation logic out of the already-long
    ff_sws_ops_list_optimize().

    Changed files

    • libswscale/ops_optimizer.c
  10. Change #252273

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision 7bce47cc63425be93ac1718e70a7e45967d14415

    Comments

    swscale/ops_optimizer: only commute swizzle ops if coefficients are identical
    Otherwise, this is invalid; as the result of applying the next operation
    after channel duplication may not commute with the result of duplicating
    the result of applying the next operation on only one channel.
    
    In practice, this was using the last seen channel's coefficients.
    
    Note that this did not actually affect anything in practice, because the only
    relevant ops (MIN/MAX) were always generated with identical coefficients for
    identical channel ranges.
    
    However, it will matter moving forwards, as e.g. dither ops may not be
    commuted freely if their matrix offsets differ per channel.

    Changed files

    • libswscale/ops_optimizer.c
  11. Change #252274

    Category ffmpeg
    Changed by Niklas Haas <gitohnoyoudont@haasn.dev>
    Changed at Mon 15 Dec 2025 15:31:58
    Repository https://git.ffmpeg.org/ffmpeg.git
    Project ffmpeg
    Branch master
    Revision 18edb246c80902e192c464fb9b7d6b15d9c11557

    Comments

    swscale/ops_optimizer: correctly commute swizzles with dither ops
    This requires updating the order of the dither matrix offsets as well. In
    particular, this can only be done cleanly if the dither matrix offsets are
    compatible between duplicated channels; but this should be guaranteed after
    the previous commits.
    
    As a side note, this also fixes a bug where we pushed SWS_OP_SWIZZLE past
    SWS_OP_DITHER even for very low bit depth output (e.g. rgb4), which led to
    a big loss in accuracy due to loss of per-channel dither noise.
    
    Improves loss of e.g. gray -> rgb444 from 0.00358659 to 0.00261414,
    now beating legacy swscale in these cases as well.

    Changed files

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