Builder ffmpeg64-solaris10-i386 Build #14152

Results:

Failed

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git updating ( 19 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. Zhao Zhili

   zhilizhaoohnoyoudont@tencent.com

Timing:

All Changes:

:

1. Change #281998

   Category	ffmpeg
   Changed by	Zhao Zhili <zhilizhaoohnoyoudont@tencent.com>
   Changed at	Thu 17 Sep 2026 04:47:35
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	23aea1374579d261a70f42a6eec6effb5ea6d6df

   Comments

   avcodec/videotoolboxenc: fix use-after-free of strings
   av_map_videotoolbox_color_*_from_av() returns borrowed references:
   CoreVideo constants, or strings owned by CoreVideo's per-process
   codepoint cache. vtenc_reset() released the stored strings, which for
   codepoints without a constant name dropped the last reference and
   freed the cached instance. CoreVideo kept handing the pointer out, so
   the next encoder open or VT session restart in the same process passed
   a dangling string to VTSessionSetProperty() and crashed.
   
   Crash can be reproduced with:
     ffmpeg -f lavfi -i testsrc2=d=2,setparams=color_trc=vlog \
       -c:v h264_videotoolbox -y a.mp4 \
       -c:v h264_videotoolbox -y b.mp4

   Changed files

   • libavcodec/videotoolboxenc.c

2. Change #281999

   Category	ffmpeg
   Changed by	Zhao Zhili <zhilizhaoohnoyoudont@tencent.com>
   Changed at	Thu 17 Sep 2026 04:47:35
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	1ecf42935734174a289eb5b2ea37542f3403f83f

   Comments

   avutil/hwcontext_videotoolbox: document mapping string ownership
   The color mapping functions return CFStringRefs borrowed from CoreVideo,
   but the header did not say so. Callers that assumed Create semantics and
   released the result freed CoreVideo's internal codepoint cache entries,
   crashing later users of the same value.
   
   Also return NULL, not 0, in the docs when no equivalent is found.

   Changed files

   • libavutil/hwcontext_videotoolbox.h