Builder ffmpegsos-solaris10-i386 Build #14316

Results:

Failed

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpegsos-solaris10-i386' triggered this build

Steps and Logfiles:

1. git updating ( 7 secs )
   1. stdio
2. shell  
   1. - no logs -
3. shell_1  
   1. - no logs -
4. shell_2  
   1. - no logs -
5. shell_3  
   1. - no logs -
6. shell_4  
   1. - no logs -
7. shell_5  
   1. - no logs -

Build Properties:

Forced Build Properties:

Responsible Users:

1. Lynne

   devohnoyoudont@lynne.ee

Timing:

All Changes:

:

1. Change #282311

   Category	ffmpeg
   Changed by	Lynne <devohnoyoudont@lynne.ee>
   Changed at	Sun 20 Sep 2026 15:59:43
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	ab40edd55ba26a5c974a60cdfc84a8cc0e9b74fb

   Comments

   prores_raw: signal the end of the frame setup to frame threads
   The decoder advertises frame threading but never called
   ff_thread_finish_setup(), so the framework only let the next frame
   thread start once the current frame was fully decoded. As frame
   threading takes precedence over slice threading, the default thread
   configuration decoded one frame at a time on one core.
   
   Signal the end of the setup once the frame buffer and the hwaccel
   private data are allocated, as the ProRes decoder does. A 4264x2408
   RAW HQ clip goes from 8.4 to 49 fps with the default threading on 12
   cores, with identical output.

   Changed files

   • libavcodec/prores_raw.c

2. Change #282312

   Category	ffmpeg
   Changed by	Lynne <devohnoyoudont@lynne.ee>
   Changed at	Sun 20 Sep 2026 15:59:46
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	87e780662bb58b6d69c41aa7df2272401bb21caf

   Comments

   dpx: signal the end of the frame setup to frame threads
   Since the decoder gained an update_thread_context() for the hwaccel
   pixel format handoff, the framework no longer calls
   ff_thread_finish_setup() on its behalf, and the decoder never called it
   itself, so every frame thread waited for the previous frame to be
   fully decoded before starting. With no slice threading to fall back
   on, the decoder ran on one core whatever the thread count.
   
   Signal the end of the setup once the frame buffer and the hwaccel
   private data are allocated. Decoding a 3840x2160 10-bit sequence goes
   from no speedup at all to 1.5x on 12 threads, bound by the memory
   bandwidth of the unpacking, with identical output.

   Changed files

   • libavcodec/dpx.c

3. Change #282313

   Category	ffmpeg
   Changed by	Lynne <devohnoyoudont@lynne.ee>
   Changed at	Sun 20 Sep 2026 15:59:48
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	e7782ef185fefcc4ec087b98cedc7eee60d36100

   Comments

   apv_decode: allocate the hwaccel private data unconditionally
   ff_hwaccel_frame_priv_alloc() is a no-op without a hwaccel, so the
   check around it is redundant.

   Changed files

   • libavcodec/apv_decode.c