Builder ffmpeg64-solaris10-i386 Build #14124

Results:

Failed

SourceStamp:

BuildSlave:

Reason:

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

Steps and Logfiles:

1. git updating ( 7 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. Frank Plowman

   postohnoyoudont@frankplowman.com

Timing:

All Changes:

:

1. Change #281642

   Category	ffmpeg
   Changed by	Frank Plowman <postohnoyoudont@frankplowman.com>
   Changed at	Sun 13 Sep 2026 11:37:40
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	2b3609ab615065700939426509bea08779bcd681

   Comments

   avcodec/vvc: Skip over the current picture in find_ref_idx
   In VVC, there are two schemes for addressing reference pictures in
   the DPB:
   1. Normally, the POC of the reference picture is signaled using a delta
      from the current picture POC.
   2. In the case of long-term reference pictures (LTRPs), which may be far
      away from the current POC, the absolute value of the LTRP POC is
      signalled.  This scheme has two sub-schemes:
      a. Signalling the entirety of the absolute value of the LTRP
         POC would be expensive, so in most cases we only signal the
         sps_log2_max_pic_order_cnt_lsb_minus4 + 4 least-significant bits
         of the LTRP POC.
      b. In the case of a collision in the least-significant bits,
         the full POC is signalled.
   
   Both schemes are implemented in find_ref_idx.  The use_msb parameter
   of find_ref_idx is nonzero in the case of schemes 1 and 2b, and zero in
   the case of scheme 2a.
   
   This commit fixes a bug in scheme 2a.  The issue arises from the fact
   that the current picture is stored in the DPB at the time find_ref_idx
   is invoked in FFmpeg's implementation, whereas in the specification the
   current picture is not yet considered part of the DPB.  The current
   picture may have a POC which shares least-significant bits with an LTRP.
   The specification does not identify this as a collision however (see the
   condition in 7.4.10, under the semantics of
   delta_poc_msb_cycle_present_flag), and so scheme 2a is used rather than
   scheme 2b.  If the current frame precedes the correct LTRP in the DPB,
   FFmpeg's implementation then interprets the signalling to mean a frame
   which references itself.  The problematic callsite identifies this as an
   issue and returns an AVERROR_INVALIDDATA, but this scenario can occur in
   valid bitstreams.  For example, the conformance bitstream
   LTRP_A_ERICSSON_3 has one such instance.  FFmpeg gets away with decoding
   it currently because the LTRP precedes the current picture in the DPB,
   but this is by chance rather than design.
   
   The commit addresses this issue by skipping over the current picture
   inside the main loop of find_ref_idx.  An unambiguous reference to the
   current picture is still syntactically possible but illegal when using
   scheme 2b.  The handling of this case is moved from find_ref_idx to the
   caller, which allows for simplifying find_ref_idx.
   
   Signed-off-by: Frank Plowman <post@frankplowman.com>

   Changed files

   • libavcodec/vvc/refs.c

2. Change #281644

   Category	ffmpeg
   Changed by	Frank Plowman <postohnoyoudont@frankplowman.com>
   Changed at	Sun 13 Sep 2026 11:42:02
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	7523428c26bdb0b2302303534be591fe73178ab6

   Comments

   tests/fate/vvc: Add fate-vvc-curr-ltrp-alias
   Regression test for 2b3609ab615065700939426509bea08779bcd681
   
   Signed-off-by: Frank Plowman <post@frankplowman.com>

   Changed files

   • tests/fate/vvc.mak
   • tests/ref/fate/vvc-curr-ltrp-alias