Garbage DTS for short sequences

[Akilan-Sivakumar]

BB Issue #1029
Original issue created by jaubourg (bitbucket username :jaubourg).
Created on Bitbucket: 2026-04-01
Last updated on Bitbucket: 2026-04-02

Hey there,

We hit quite the weird, random bug when transcoding very short animated GIFs to h265 videos using FFmpeg.

the bug

When encoding fewer than m_bframeDelay + 1 frames (so 3 by default), encoding succeeds fine but the output packet's DTS is oftentimes pure nonsense.

the source of the problem

Took us some very long hours to pinpoint the reason within source/encoder/encoder.cpp.

The Encoder constructor there never initializes m_bframeDelayTime, m_prevReorderedPts nor m_firstPts. m_bframeDelayTime is only assigned when m_pocLast == m_bframeDelay which needs at least 3 input frames with default settings. Send fewer and flush? It's whatever was on the heap: could be zero, could be millions.

Then the DTS computation goes:

frameEnc[0]->m_dts = m_encodedFrameNum > m_bframeDelay
    ? prevReorderedPts[(m_encodedFrameNum - m_bframeDelay) % m_bframeDelay]
    : frameEnc[0]->m_reorderedPts - m_bframeDelayTime;  // heap garbage

That subtracts garbage from the PTS. FFmpeg's muxer rightfully chokes on the resulting DTS and rejects it with a good old EINVAL.

the fix

Three small lines in the constructor:

m_firstPts = 0;
m_bframeDelayTime = 0;
m_prevReorderedPts[0] = m_prevReorderedPts[1] = 0;

With m_bframeDelayTime at 0, short sequences get DTS = reorderedPts which is correct since there's no actual reordering happening with so few frames.

I attached a patch file that does just that right before we build x265.

version concerned

Reproduced on x265 4.1 (ABI 215). Still an issue in master.

Attachments:

fix-uninitialized-dts-vars.patch