Builder ffmpeg64-solaris10-i386 Build #12700

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git update ( 5 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 ( 9 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_64.sh' failed ( 1 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Martin Storsjö

   martinohnoyoudont@martin.st

Timing:

All Changes:

:

1. Change #247551

   Category	ffmpeg
   Changed by	Martin Storsjö <martinohnoyoudont@martin.st>
   Changed at	Tue 04 Nov 2025 11:23:31
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	8313dc1120a221962541000ae261c2f1fbc53a9e

   Comments

   movenc: Make hybrid_fragmented retain the fragmented form headers
   This makes the final file truly hybrid: Externally the file
   is a regular, non-fragmented file, but internally, the fragmented
   form also exists un-overwritten.
   
   To make any use of that, first, the fragments need to be muxed in
   a position independent form, i.e. with empty_moov+default_base_moof
   (or the dash or cmaf meta-flags).
   
   Making use of the fragmented form when the file is finalized is
   not entirely obvious though. One can dump the contents of the
   single mdat box, and get the fragmented form. (This is a neat
   trick, but not something that anybody really is expected to
   want to do.)
   
   The main expected use case is accessing fragments in the form of
   byte range segments, for e.g. HLS.
   
   Previously, the start of the file would look like this:
   
   - ftyp
   - free
   - moov
    - (moov contents)
   
   After finalizing the file, it would look like this:
   
   - ftyp
   - free
   - mdat (previously moov)
    - (moov contents)
   
   In this form, the size and type of the original moov box were
   overwritten, and the original moov contents is just leftover
   as unused data in the mdat box.
   
   To avoid this issue, the start of the file now looks like this:
   
   - ftyp
   - free
   - free
    - ftyp
   - moov
    - (moov contents)
   
   The second, hidden ftyp box inside mdat, would normally never be
   seen.
   
   After finalizing, the difference is that the mdat box now is
   extended to cover the ftyp and the whole moov including its header
   (and all the following fragments).
   
   I.e., the start of the file looks like this:
   
   - ftyp
   - free
   - mdat
    - ftyp
    - moov
     - (moov contents)
   
   This allows accessing the "ftyp+moov" pair sequentially as such,
   with a byte range - this range is untouched when finalizing,
   producing the same ftyp+moov pair both while writing, when the
   file is fragmented, and after finalizing, when the file is
   transformed to non-fragmented externally.
   
   Note; the sequential two "free+free" boxes may look slightly
   silly; it could be tempting to make the second one an mdat
   from the get-go. However, some players of fragmented mp4 (in
   particular, Apple's HLS player) bail out if the initialization
   segment contains an mdat box - therefore, use a free box.
   
   It could also be possible to use just one single free box with
   8 bytes of padding at the start - but that would require more
   changes to the finalization logic.
   
   For a segmenting user of the muxer, the only unclarity is how
   to determine the right byte range for the internal ftyp+moov
   pair. Currently, this requires parsing the muxer output and skip
   past anything up to the start of the non-empty free box.

   Changed files

   • libavformat/movenc.c
   • tests/fate/mov.mak
   • tests/ref/lavf/mov_hybrid_frag