Builder ffmpegsos-solaris10-sparc Build #13447

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 ( 10 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_sos.sh' failed ( 2 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Marton Balint

   cusohnoyoudont@passwd.hu
2. Niklas Haas

   gitohnoyoudont@haasn.dev

Timing:

All Changes:

:

1. Change #268117

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 23 May 2026 10:41:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	0d123a3c23b8da2a6869976fd35fef24584a13c2

   Comments

   fftools/ffmpeg_sched: use macros for schedule_update_locked() loops
   Instead of awkwardly looping over the type, just split this up into
   multiple loops. The loss in complexity seems worth the loss in conciseness
   to me, and more importantly, this allows us to easily add more waiter types.
   
   Sponsored-by: nxtedition AB
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • fftools/ffmpeg_sched.c

2. Change #268118

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 23 May 2026 10:41:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	04888287b38ef4b45351fad76cb32c2510628fe7

   Comments

   fftools/ffmpeg_sched: fix sch_stop() and schedule_update_locked() race
   schedule_update_locked() is supposed to be a no-op when `sch->terminate`
   is 1. However, there is a TOCTOU error here, where a different thread may
   currently be executing schedule_update_locked(), having successfully passed
   the sch->terminate check but without actually updating the choke status.
   
   This does not matter for the current code, but will matter with the following
   commit, where it creates the theoretical possibility of a race where sch_stop()
   is trying to choke the demuxers (and unchoke the decoders) while
   schedule_update_locked() is simultaneously trying to choke the decoders,
   leading to a deadlock if the last decoder is left choked and unable to
   propagate EOF downstream.
   
   The cleanest solution is to just take the scheduler lock while updating the
   choke status here. This ensures that any other schedule_update_locked() calls
   will have completed.
   
   Sponsored-by: nxtedition AB
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • fftools/ffmpeg_sched.c

3. Change #268119

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 23 May 2026 10:41:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	6a563dab71d3bcfcd709ace9a3e7d7548d69f772

   Comments

   fftools/ffmpeg_sched: allow choosing nodes to unchoke
   This level of granularity will help for the upcoming patch.
   
   Sponsored-by: nxtedition AB
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • fftools/ffmpeg_sched.c

4. Change #268120

   Category	ffmpeg
   Changed by	Marton Balint <cusohnoyoudont@passwd.hu>
   Changed at	Sat 23 May 2026 10:41:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	f48e5d4db451cc5174a6c67979c2d39cc0b42a52

   Comments

   fftools/ffmpeg_filter: rate control all filter graphs
   It was never reliable to detect if a filtergraph have sources, because a filter
   can act as a source only after some time, for example the loop filter.
   
   So it is better to remove the source detection entirely and always give the
   scheduler an oppurtunity to stop processing.
   
   Fixes ticket #11604.
   
   Signed-off-by: Marton Balint <cus@passwd.hu>
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • fftools/ffmpeg_filter.c

5. Change #268121

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 23 May 2026 10:41:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	321b0e36a33a23c68fbfb14559e555ea65646bd6

   Comments

   fftools/thread_queue: add `flags` parameter to tq_receive()
   I want to use this to allow a non-blocking use of this function.
   
   Sponsored-by: nxtedition AB
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • fftools/ffmpeg_sched.c
   • fftools/thread_queue.c
   • fftools/thread_queue.h

6. Change #268122

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 23 May 2026 10:41:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	95391352b50b272e13c49353bf1d62b6b77d6a54

   Comments

   fftools/thread_queue: add THREAD_QUEUE_FLAG_NO_BLOCK
   Exactly what it says on the tin. There is some ambiguity as to whether this
   should also prevent reading from *choked*, as opposed to empty queue, but
   I think it makes sense to consider them equivalent, as I struggle to think
   of a use case where it would be beneficial to allow draining a queue that
   was explicitly choked by the upstream (to e.g. prevent further reads).
   
   Sponsored-by: nxtedition AB
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • fftools/thread_queue.c
   • fftools/thread_queue.h

7. Change #268123

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 23 May 2026 10:41:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	2b72d5243ca1ac8687e6ffb42e186c81f42cad2b

   Comments

   fftools/ffmpeg_sched: drain incoming frames before blocking filters
   When a filter is choked, but upstream threads are trying to write to its input,
   this can result in the filter's input queue getting stuck. Normally, the
   unchoke_downstream() logic would prevent this from happening, since the
   filter would itself get unchoked as a result of upstream decoders receiving
   pressure from the demuxer.
   
   However, upcoming changes to this logic will require weakening this upstream
   unchoking logic, so preventing the deadlock in a more elegant way helps with
   making the code more robust.
   
   Sponsored-by: nxtedition AB
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • fftools/ffmpeg_sched.c

8. Change #268124

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 23 May 2026 10:41:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	03dfac563018e6e8b81e331ebae0732d8edfe754

   Comments

   fftools/ffmpeg_sched: allow throttling decoder outputs
   This is a departure from the conventional idea of decoders always outputting
   data as fast as possible. Instead, this allows decoders to be throttled in the
   same way filter graphs can be.
   
   This comes into play when e.g. a demuxer is feeding into two decoders, but
   only one of the two decoders is actually currently needed (e.g. due to
   A/V misalignment). In that case, what typically happens is that the unneeded
   decoder alse decodes all frames, and then piles them up on the "buffersrc"
   filter's downstream link (growing indefinitely).
   
   Another issue this solves manifests when e.g. a single demuxer is feeding many
   decoders that all try to feed frames to the same filter graph. In this case,
   all decoders run as fast as posssible, leading to lock contention on the
   filter graph input queue; resulting in (again) many frames piling up on the
   buffersrc (or downstream filters) for the unneeded inputs that are not actually
   the bottleneck, while the input that's actually undersatisfied can end up
   starved for CPU time, possibly for long enough to exhaust memory limits. The
   normal rate limiting fails to apply in this scenario because all decoders share
   a single demuxer, and are hence rate-limited only by the demuxer speed; whereas
   the demuxer is not choked because from the PoV of the scheduler, the filter
   graph is simply not getting enough frames.
   
   In a more general sense, there's a philosophical argument to be made here.
   Since a decoder is typically also a decompressor, it produces more data than
   it consumes. So, it a sense, it's acting like a type of producer also - in
   the same way that a filter graph can produce more input that outputs.
   
   Solve all of these issues by allowing decoders to be output-choked, which
   gives the scheduler control over when decoders are allowed to output frames.
   This does mean we have to add some sort of internal packet queue, because the
   decoder thread may need to continue *accepting* upstream packets from the
   demuxer (or else we risk stalling the demuxer), but defer the actual decoding
   by placing them inside an internal "overflow" queue.
   
   This effectively simulates a sort of "filter graph"-type semantics but
   for the decoder queue.
   
   This overflow logic is fairly self-contained inside `sch_dec_receive`, though
   it is quite nontrivial. I have added as much documentation as is hopefully
   needed to understand the logic.
   
   Importantly, we cannot simply unlimit the decoder input thread queue because
   the demuxer relies on backpressure from the decoder to rate limit itself. (Note
   that demuxers may only be active if there is at least one downstream decoder
   that is alse active, so we always have at least one decoder providing
   backpressure)
   
   Sponsored-by: nxtedition AB
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • fftools/ffmpeg_sched.c