Builder ffmpegsos-solaris10-sparc Build #12032

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 ( 1 mins, 5 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 ( 9 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_sos.sh' failed ( 5 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 #240946

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Mon 28 Jul 2025 10:56:10
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	603334a04362e7a466cbdf9a25892ded167e3ce0

   Comments

   avfilter/vf_premultiply: use correct premultiplication formula
   The previous formula was introduced without justification in 6e713841e8,
   and the only thing Paul had to say about it over IRC was that it was copied
   from an unspecified source on the internet.
   
   I decided to do some testing and came to the conclusion that this term not
   only produces "illegal" files, but also lowers PSNR score, over the naive
   implementation without this extra term.
   
   Here are the results of a round-trip test, using allrgb/allyuv (respectively)
   as the input, and fade=alpha=yes:n=256 to cycle through every possible alpha
   value, comparing the round-trip output against the input:
   
   Before patch:
     PSNR r:26.677431 g:26.677431 b:26.677431 a:inf average:27.926818 min:6.012093 max:55.400791
     PSNR y:26.677431 u:21.101981 v:21.101981 a:inf average:23.548981 min:9.013835 max:53.182303 (full)
     PSNR y:27.348055 u:21.101981 v:21.101981 a:inf average:23.625238 min:9.554991 max:45.652221 (limited)
   
   After patch:
     PSNR r:27.321996 g:27.321996 b:27.321996 a:inf average:28.571384 min:6.012093 max:52.424553
     PSNR y:27.321996 u:23.187879 v:23.187879 a:inf average:25.431773 min:9.013835 max:50.199232 (full)
     PSNR y:27.868544 u:23.187879 v:23.187879 a:inf average:25.515660 min:9.554991 max:45.078298 (limited)
   
   It's worth pointing out that previous version sometimes artificially inflates
   PSNR by producing values that are too high (i.e. RGB > A), such as for the
   input pair (R = 255, A = 2) which should give R = 2, but actually gives R = 3
   under the old logic.
   
   As a second evaluation without this shortcoming, here is a comparison against
   the reference value computed with a floating point format:
   
   Before patch:
     PSNR r:53.600599 g:53.957833 b:53.540948 a:inf average:54.945316 min:50.508901 max:inf (premul only)
     PSNR r:30.734183 g:30.734183 b:30.734183 a:inf average:31.983570 min:12.058264 max:inf (round-trip)
   
   After patch:
     PSNR r:61.751104 g:65.239091 b:61.339191 a:inf average:63.710714 min:55.441130 max:inf (premul only)
     PSNR r:32.611851 g:32.611851 b:32.611851 a:inf average:33.861238 min:12.058264 max:inf (round-trip)

   Changed files

   • libavfilter/vf_premultiply.c