Builder ffmpeg64-solaris10-i386 Build #13164

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 ( 6 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 ( 6 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 ( 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 #257136

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 07 Feb 2026 11:02:36
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	5f95a1e714f4e9dc71eebb016c2acf41c2aed2a9

   Comments

   avformat/http: fix noop seek check
   This fails to consider the case of whence == SEEK_END and the resulting
   offset happening to exactly match the current position.
   
   Reorder the check to compute the target position first, then compare.

   Changed files

   • libavformat/http.c

2. Change #257137

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 07 Feb 2026 11:02:36
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	19cae9151c0b053467f2c7f54735197962700d17

   Comments

   avformat/http: print error on HTTP response failure
   This currently fails silently with zero indication of what the problem might
   be, which tripped me up a bit while debugging.

   Changed files

   • libavformat/http.c

3. Change #257138

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 07 Feb 2026 11:02:36
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	ca2c5ff4120439e52257154d4528da609570b7f0

   Comments

   avformat/http: parse range size from Content-Range header
   In the event that the range returned is smaller than the true filesize, we
   should only expect to receive that many bytes - not the entire rest of the
   file.
   
   This commit is theoretically non-functional on its own, since any conforming
   HTTP server will always return us the full file range, but I wanted to split
   it off from the subsequent changes in order to make review easier.

   Changed files

   • libavformat/http.c

4. Change #257139

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 07 Feb 2026 11:02:36
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	6336fa33358cd860f74c8be4772bbc303311b71e

   Comments

   avformat/http: return EIO if s->hd is NULL
   This could conceivably happen currently if the user tries reading more
   bytes after the last chunk has already been received. In this case,
   we currently segfault - but simply returning AVERROR(EIO) seems more
   reasonable and lets the higher end retry the connection in this case.

   Changed files

   • libavformat/http.c

5. Change #257140

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 07 Feb 2026 11:02:36
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	bf1722a9c6a6fcfeb7c35a47a3a1f4530402dcba

   Comments

   avformat/http: request more data after partial response
   If the Content-Range indicates a smaller range than what we expected,
   we should send a new request for the remainder before attempting to read
   more.
   
   Again, this commit is theoretically non-functional on its own, since any
   conforming HTTP server should give us the entire range we asked for in the
   first place, but it is semantically independent from and prepares us for the
   following changes.

   Changed files

   • libavformat/http.c

6. Change #257141

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 07 Feb 2026 11:02:36
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	e03b034e45e68450e16f913c8aaf5ec362bc1446

   Comments

   avformat/http: re-use keep-alive connection for small seeks
   When the previous reply was a partial response (e.g. due to a seek to the
   end of the file), and the remaining data from that partial response is
   below the short seek size threshold, we can serve this seek by just draining
   that data and re-using the existing connection.
   
   This can currently only happen when using keep-alive connections
   (-multiple_requests 1) and seeking from the end of the file to somewhere
   else, in which case the file's tail can be drained and the connection re-used.
   
   Under other circumstances, however, we still need to force a reconnection,
   because we do not yet send partial range requests. (This will be changed in the
   following commit)
   
   We need to take special care not to regress the existing fallback logic
   for when `http_open_cnx` fails, so here is a quick case analysis:
   
   non-drain path:
   - identical to the current
   
   soft drain fails: (ffurl_read error path)
   - s->hd = old_hd = NULL
   - http_open_cnx() always opens a new connection
   - on failure, old buffer is restored and s->hd remains NULL
   
   soft drain succeeds, http_open_cnx() fails:
   - s->hd is set to NULL by http_open_cnx() failure path
   - old_hd was never set, so remains NULL
   - old buffer is restored, s->hd remains NULL
   
   In either case, the outcome that any (previously valid) buffer is left as-is,
   the offset is unchanged, and the connection ends up closed (s->hd == NULL).
   This is okay to do after the previous change to http_buf_read, which allows
   it to internally re-open the connection if needed.

   Changed files

   • libavformat/http.c

7. Change #257142

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 07 Feb 2026 11:02:36
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	4f5d91e43fd616c6415ef08802469a7f4da25d4e

   Comments

   avformat/http: allow limiting initial request size
   Sometimes, HTTP sources require a lot of seeking during probing / header
   parsing (especially for formats like MXF). Currently, we need to completely
   tear down and re-establish the connection most times this happens, which puts
   a lot of stress on the network stack and also results in transmission of
   possibly many unnecessary bytes.
   
   This patch adds an option to allow FFmpeg to request partial ranges during
   the initialization stage. This is done until the initial request size is fully
   read, after which we fall back to the normal behavior (i.e. infinite streaming
   via an unbounded request).
   
   The usefulness of this is limited without also specifying -multiple_requests 1,
   since otherwise there is little point to requesting partial ranges to begin
   with. (However, it is semantically independent, so we keep it that way.)

   Changed files

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

8. Change #257143

   Category	ffmpeg
   Changed by	Niklas Haas <gitohnoyoudont@haasn.dev>
   Changed at	Sat 07 Feb 2026 11:02:36
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	b8daba42cdb4b91e793b91ef3055797b0b7611bd

   Comments

   avformat/http: report connection statistics
   Helpful to track the impact of options like -multiple_requests, -probing_size
   or -short_seek_size.

   Changed files

   • libavformat/http.c