Builder ffmpegsos-solaris10-sparc Build #14239

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 ( 17 secs )
   1. stdio
2. shell 'gsed -i ...' ( 1 secs )
   1. stdio
3. shell_1 'gsed -i ...' ( 1 secs )
   1. stdio
4. shell_2 'gsed -i ...' failed ( 0 secs )
   1. stdio
5. shell_3 './configure --samples="../../../ffmpeg/fate-suite" ...' failed ( 12 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 2 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config_sos.sh' failed ( 1 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Kacper Michajłow

   kasper93ohnoyoudont@gmail.com

Timing:

All Changes:

:

1. Change #285491

   Category	ffmpeg
   Changed by	Kacper Michajłow <kasper93ohnoyoudont@gmail.com>
   Changed at	Sun 11 Oct 2026 19:31:02
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	d9242028a6362b86dffa254b696c36bc41fac620

   Comments

   avformat/hls: fix reading byte-range segments after the first one
   Seeking an input opened with the http or libcurl "offset" option to the
   next segment's offset does not work, because its AVIOContext counts from
   0 while the protocol seeks to file offsets, so the seek skipped as many
   bytes as the request started at. A seek also cannot extend a request past
   its end offset. Keep reading from the same input when the next segment
   follows within the requested range, and open it with a new request
   otherwise. Keep the requested end with each input, extend prefetched
   requests over their run too, and reuse a connection only after its reply
   was read to the end.
   
   Only hls.c and dashdec.c pass "offset". The AVIOContext starts its
   position at 0 and never learns the protocol's start offset. Initializing
   the position from the protocol in ffio_fdopen would fix that for
   everyone, but the crypto and cache protocols and probing with an offset
   report positions in their own coordinates and break with it, so avoid
   the seek here instead.
   
   Note that external users that pass "offset" themselves see the same
   thing, positions and seeks on such an input are relative to the request
   start rather than to the file, and this commit only avoids the seek in
   hls.c instead of fixing that accounting.
   
   Fixes: 0616685b1e
   Fixes: #25000
   Signed-off-by: Kacper Michajłow <kasper93@gmail.com>

   Changed files

   • libavformat/hls.c