`DecodeFrameNoDelay` yields frames one call later in 2.5.0 than in 2.4.1

[torokati44]

With the same (attached) example program, which has some test frame data hardcoded in it, I get different results with OpenH264 2.4.1 and 2.5.0:

Output of LD_PRELOAD=./libopenh264-2.4.1-linux64.7.so ./test:

Version 2.4.1

Decoding nalu 0 succeeded W/H: 0 0 No output frame

Decoding nalu 1 succeeded W/H: 0 0 No output frame

Decoding nalu 2 succeeded W/H: 256 160 No output frame

Decoding nalu 3 succeeded W/H: 256 160 Output frame: 16 16 16 16 16 16 16 16

Decoding nalu 4 succeeded W/H: 256 160 No output frame

Decoding nalu 5 succeeded W/H: 256 160 Output frame: 235 16 16 16 16 16 16 16

Decoding nalu 6 succeeded W/H: 256 160 Output frame: 235 235 16 16 16 16 16 16

Decoding nalu 7 succeeded W/H: 256 160 Output frame: 235 235 235 16 16 16 16 16

Decoding nalu 8 succeeded W/H: 256 160 Output frame: 235 235 235 235 16 16 16 16

Output of LD_PRELOAD=./libopenh264-2.5.0-linux64.7.so ./test:

Version 2.5.0

Decoding nalu 0 succeeded W/H: 0 0 No output frame

Decoding nalu 1 succeeded W/H: 0 0 No output frame

Decoding nalu 2 succeeded W/H: 256 160 No output frame

Decoding nalu 3 succeeded W/H: 256 160 Output frame: 16 16 16 16 16 16 16 16

Decoding nalu 4 succeeded W/H: 256 160 No output frame

Decoding nalu 5 succeeded W/H: 256 160 No output frame

Decoding nalu 6 succeeded W/H: 256 160 Output frame: 235 16 16 16 16 16 16 16

Decoding nalu 7 succeeded W/H: 256 160 Output frame: 235 235 16 16 16 16 16 16

Decoding nalu 8 succeeded W/H: 256 160 Output frame: 235 235 235 16 16 16 16 16

The included test data looks like this: https://github.com/user-attachments/assets/76d1ba59-27c2-404b-9a19-6cec64ad216b

NALUs 0 and 1 are the SPS and PPS, respectively.

The eight logged numbers for every output frame are the luminosities of each of the 32x32 pixel squares at the top (235 for white, 16 for black). Notice how in 2.4.1, the 3rd NALU yields the first frame, then the 4th one doesn't (understandably, it has to be reordered), but then decoding NALUs 5th and 6th again result in frames, in the correct order. In 2.5.0, decoding neither the 4th or 5th NALUs return a frame, and from the 6th one on, they all start coming in again, but with one more call of latency.

This was probably caused by https://github.com/cisco/openh264/pull/3752, and blocks https://github.com/ruffle-rs/ruffle/pull/18581.

I honestly don't understand how the "decoding latency on Qualcomm hardware decoders" (as noted in the linked suspect PR) has anything to do with this.

The example program: main.zip

[BenzhengZhang]

@fippo Could you check this suspected regression?

[fippo]

That #3752 was a encoder change and the SPS shows pic_order_cnt_type=0 so this should not be related?

#3787 might be it, should be easy to check by reverting it and running the test program.

[torokati44]

That #3752 was a encoder change and the SPS shows pic_order_cnt_type=0 so this should not be related?

That was just a guess on my part, it's entirely possible that it was wrong.

[fippo]

I did a bisect with the test provided (great, that should be a unit test!) and that points to #3734

[joakim-tjernlund]

I did a bisect with the test provided (great, that should be a unit test!) and that points to #3734

There is this change:

 if (bTmpNewSeqBegin) {
    if (pCtx->pStreamSeqNum)
      (*pCtx->pStreamSeqNum)++;
    else
      pCtx->iSeqNum++;
  }

That pCtx->iSeqNum++ was not there before, maybe it should be removed?

[joakim-tjernlund]

or this:

  if (pCtx->pStreamSeqNum)
    pCtx->iSeqNum = *pCtx->pStreamSeqNum;

maybe needs to be:

 if (bTmpNewSeqBegin && pCtx->pStreamSeqNum)
    pCtx->iSeqNum = *pCtx->pStreamSeqNum;

[torokati44]

2.5.1 is still affected.

[BenzhengZhang]

@tyan0 Could you pls check this issue?

[tyan0]

I'll look into it. Please wait a while.

[tyan0]

I found the code removed in the commit c0e5ea286c31 affects the issue. I create new pull request https://github.com/cisco/openh264/pull/3868

Sorry for inconvenience.

[torokati44]

https://github.com/cisco/openh264/pull/3868#issuecomment-2732966884 ... please? 🥺

[torokati44]

I would send a backport PR, but since there's no branch named v2.5.x, or similar, I can't choose a proper base for it.

Merging into the branch named openh264v2.5.1 (which is redundant with the tag 2.5.1 BTW) would be obviously ill-advised, as that would move it from the commit which the 2.5.1 release was actually made of...

[torokati44]

2.6.0 is still affected