Builder ffmpeg-solaris10-i386 Build #12830

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpeg-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 ( 8 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.sh' failed ( 1 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 #250083

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Wed 26 Nov 2025 14:15:16
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	623669a02cd6cdc5598801bf31fd77199e61bae1

   Comments

   avfilter/buffersrc: add av_buffersrc_get_status()
   There is currently no way for API users to know that a buffersrc is no longer
   accepting input, except by trying to feed it a frame and seeing what happens.
   
   Of course, this is not possible if the user does not *have* a frame to feed,
   but may still wish to know if the filter is still accepting input or not.
   
   Since passing `frame == NULL` to `av_buffersrc_add_frame()` is already treated
   as closing the input, we are left with no choice but to introduce a new
   function for this.
   
   We don't explicitly return the result of `ff_outlink_get_status()` to avoid
   leaking internal status codes, and instead translate them all to AVERROR(EOF).

   Changed files

   • doc/APIchanges
   • libavfilter/buffersrc.c
   • libavfilter/buffersrc.h
   • libavfilter/version.h

2. Change #250085

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Wed 26 Nov 2025 14:15:16
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	38a5fcc02c2ef1bcb37d2e53eddde8eccc0c75ed

   Comments

   fftools/ffmpeg_filter: close all no-longer needed inputs
   Currently, the thread loop of ffmpeg_filter essentially works like this:
   
   while (1) {
       frame, idx = get_from_decoder();
       err = send_to_filter_graph(frame);
       if (err) { // i.e. EOF
           close_input(idx);
           continue;
       }
   
       while (filtered_frame = get_filtered_frame())
           send_to_encoder(filtered_frame);
   }
   
   The exact details are not 100% correct since the actual control flow is a bit
   more complicated as a result of the scheduler, but this is the general flow.
   
   Notably, this leaves the possibility of leaving a no-longer-needed input
   permanently open if the filter graph starts producing infinite frames (during
   the second loop) *after* it finishes reading from an input, e.g. in a filter
   graph like -af atrim,apad.
   
   This patch avoids this issue by always querying the status of all filter graph
   inputs and explicitly closing any that were closed downstream; after each round
   of reading output frames. As a result, information about the filtergraph being
   closed can now propagate back upstream, even if the filter is no longer
   requesting any input frames (i.e. input_idx == fg->nb_inputs).
   
   Fixes: https://trac.ffmpeg.org/ticket/11061
   See-Also: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20457#issuecomment-6208

   Changed files

   • fftools/ffmpeg_filter.c