Builder ffmpegsos-solaris10-sparc Build #13535

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 ( 7 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 ( 7 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 3 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config_sos.sh' failed ( 0 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 #269504

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Thu 04 Jun 2026 17:48:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	7cb93fb200f7b7f4493ec65fe7a2fc7716bb3690

   Comments

   avformat/http: return ENOSYS instead of UINT64_MAX for unknown filesize
   This matches the behavior of e.g. the pipe: protocol, which returns ENOSYS
   on account of ffurl_seek() not being implemented.
   
   The previous behavior of returning s->filesize directly is almost surely a
   bug, as s->filesize is UINT64_MAX when never initialized.
   
   Sponsored-by: nxtedition AB
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • libavformat/http.c

2. Change #269505

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Thu 04 Jun 2026 17:48:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	cd3f3352074d532ec7421b47efe3496dc7d1de6b

   Comments

   avformat/file: return ENOSYS for filesize query on files with follow=1
   If the input is expected to grow, we shouldn't make any assumptions about
   the file size. This matches e.g. the behavior of streamed protocols like
   chunked HTTP, which similarly return ENOSYS for streams of unknown size.
   
   Sponsored-by: nxtedition AB
   Signed-off-by: Niklas Haas <git@haasn.dev>

   Changed files

   • doc/protocols.texi
   • libavformat/file.c

3. Change #269506

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Thu 04 Jun 2026 17:48:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	56de70a2e624b7febe7877ee261f699000eea66a

   Comments

   avformat: add shared concurrent block cache protocol
   This adds a new protocol shared:URI which is distinct from the existing
   `cache:` in that it is explicity designed to be thread-safe and cross-process,
   enabling multiple ffmpeg processes (or multiple ffmpeg decoders within the same
   process) to share a single cache file, for e.g. a remote HTTP stream. As such,
   it uses a radically different internal design.
   
   To facilitate zero-knowledge cross-process interoperability, the cache file
   itself is just a memory-mapped representation of the underlying file data,
   which has the side benefit that the resulting cache file will contain a
   working copy of the streamed file (assuming the stream was read to
   completion).
   
   To keep track of which regions are cached and which are not, we use a
   secondary file that contains a minimal header along with a static bytemap of
   blocks within the file. This secondary file is also used to store metadata
   such as the filesize, if known, as well as marking "failed" blocks.
   
   Both files can grow dynamically in order to accommodate larger/growing files,
   and can be atomically updated (through the use of shared space maps). I have
   extensively checked the space map initalization and update code for race
   conditions, and I believe the current design to be solid.
   
   That said, it is the user's responsibility to some extent to ensure that the
   same URI is not used for different streams, as we rely on the URI to uniquely
   identify the cache files. That said, we use a cryptographic hash with
   sufficient collision resistance to protect against possible abuse. The lack of
   any implicit default on `-cache_dir` also means that `shared:` can't be enabled
   via URL injection to possibly access random files on the disk (or intentionally
   leak content from other streams with similar URIs, even if the cryptograhic
   hash function is broken).

   Changed files

   • configure
   • doc/protocols.texi
   • libavformat/Makefile
   • libavformat/protocols.c
   • libavformat/shared.c

4. Change #269507

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Thu 04 Jun 2026 17:48:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	ca748964fe4a5638f1d127d6fb38604c270e3617

   Comments

   avformat/shared: implement 16-bit CRC check
   Decided to split this off from the previous commit in case we
   ever want to revert it, since it does double the overhead of the spacemap
   as well as adding extra overhead to both the read and write path.
   
   Bump the cache version to 2 to reflect the changed disk format.

   Changed files

   • libavformat/shared.c

5. Change #269508

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Thu 04 Jun 2026 17:48:12
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	afce637550dea772da604afe1d284a12731a25f9

   Comments

   avformat/shared: add option to verify cache file contents
   This will effectively disable the cache but allows the cache layer to verify
   cached files against the original input file. Useful only for debugging
   the shared cache protocol itself, as file corruption can already be caught by
   the CRC check.

   Changed files

   • doc/protocols.texi
   • libavformat/shared.c