Builder ffmpeg-solaris10-sparc Build #12480

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpeg-solaris10-sparc' triggered this build

Steps and Logfiles:

1. git update ( 9 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 #243443

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Thu 21 Aug 2025 14:55:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	8e0de5d811b1828d588844a88cea35440cce0008

   Comments

   avfilter/setpts: also preserve duration when not stripping fps
   It makes sense to treat the presence of a frame duration and the presence
   of frame rate metadata identically - because both convey effectively the same
   amount of information.
   
   In f121d95 and fa110c3 respectively, this information was stripped by default,
   originally to work-around bugs when changing the PTS information of a stream
   being fed to some encoders. (See https://trac.ffmpeg.org/ticket/10886)
   
   Later, commit 959b799c restored the ability to preserve the frame rate
   medatata via the `strip_fps` option, but this option did not extend to also
   include the frame duration.
   
   This commit resolves the scenario by making `frame_rate` and `duration`
   handled in a consistent manner, so that the frame rate information is
   generally preserved unless explicitly stripped by the user.
   
   While it does regress the exact invocation presented in the trac ticket unless
   using `strip_fps=yes`, I consider this an acceptable trade-off, especially in
   light of the fact that the `fps` filter also exists and is arguably the better
   tool for the task at hand.

   Changed files

   • doc/filters.texi
   • libavfilter/setpts.c