Builder ffmpegsos-solaris10-sparc Build #12519

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 ( 13 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 ( 7 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 ( 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 #251139

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Fri 05 Dec 2025 19:42:41
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	5e56937b742b9110d38ce6fa4c7bdf2d5c355df4

   Comments

   avcodec: allow bypassing frame threading with an optional flag
   Normally, this function tries to make sure all threads are saturated with
   work to do before returning any frames; and will continue requesting packets
   until that is the case.
   
   However, this significantly slows down initial decoding latency when only
   requesting a single frame (to e.g. configure the filter graph), and also
   wastes a lot of unnecessary memory in the event that the user does not intend
   to decode more frames until later.
   
   By introducing a new `flags` paramater and a new flag
   `AV_CODEC_RECEIVE_FRAME_FLAG_SYNCHRONOUS` to go along with it, we can allow
   users to temporarily bypass this logic.

   Changed files

   • doc/APIchanges
   • libavcodec/avcodec.c
   • libavcodec/avcodec.h
   • libavcodec/avcodec_internal.h
   • libavcodec/decode.c
   • libavcodec/pthread_frame.c
   • libavcodec/version.h

2. Change #251140

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Fri 05 Dec 2025 19:42:45
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	929a2ced9ba7811136bce86293ec0b0a098c66df

   Comments

   fftools/ffmpeg_dec: decode the first frame synchronously
   In an ideal world, a filtergraph like `-i A -i B ... -filter_complex concat`
   would only keep resources in memory related to the file currently being output
   by the concat filter. So ideally, we'd open and fully decode A, then open and
   fully decode B, and so on.
   
   Practically, however, fftools wants to get one frame from each input file in
   order to initialize the filter graph (buffersrc parameters). So what happens
   currently is that fftools will request a single frame from each input A, B, etc
   that is plugged into the filtergraph.
   
   When using frame threading, the design of the decoder (ff_thread_receive_frame)
   is that it will not output any frames until we have received enough packets to
   saturate all threads. This, however, forces the decoder to buffer at least as
   many frames for each input file as we have threads, before outputting anything.
   
   By decoding the first frame synchronously, we avoid this issue and allow
   configuring the filter graph more quickly and without wasting excess resources
   on frames that will not (yet) be used.

   Changed files

   • fftools/ffmpeg_dec.c