Fix of continuation PES mpegts packets

[Taiwan22]

Hello,
I had problems streaming from my encoder when using either ristsender (librist) or srt-live-transmit (SRT).
I was getting strange timestamp jumps like these:

[07 Jun 2026, 04:28:16] MistInTSRIST:test (31961) [INFO] Timestamp jump 0d01h28m58s.157 -> 14714d05h45m19s.374, compensating. (../src/input/input_tsrist.cpp:238)
[07 Jun 2026, 04:28:16] MistInTSRIST:test (31961) [INFO] Timestamp jump 0d01h28m58s.157 -> 0d02h57m56s.577, compensating. (../src/input/input_tsrist.cpp:238)

Half of my video was blinking green.
When streaming from FFmpeg to MistServer everything worked fine, and streaming with ristsender directly to VLC also worked without issues. (same source UDP stream)

After a lot of trial and error, I found a bug in ts_stream.cpp.
When the encoder uses continuation PES packets, the PTS/DTS values are set to 0, which leads to massive timestamp jumps. We should also skip scanAnnexB for continuation PES packets, because it can result in false positives.

After fixing this, I ran into another issue with OBS Studio. In my case, OBS does not set the data_align_bit, which caused the error:
"Continuation PES (align=0) for track XX ts=XXX but no build packet exists"
So I added additional detection to handle this case.

I've included a capture of my UDP stream data so you can test it.
video_pcap.zip

[Thulinma]

Thanks for this! At first glance this looks great, but I'm wondering if not scanning for annex B start codes in continuation packets is the right choice: PES packets containing multiple NAL units in a row is fairly common, after all (though yes, it's fairly rare to have one start after the first TS packet of the PES packet). There should be no false positives, as the payload is supposed to use emulation prevention to mask startcode-alike byte sequences... But perhaps I'm missing something, so please do correct me if I'm wrong.

Also: I am guessing you're okay with your code being published under the same "Unlicense" license the rest of the codebase is also published under? Since you send in this PR I am guessing the answer is "yes", but it's always good to have explicit permission for such things.

[Taiwan22]

Hi, you are right. I didn’t know about emulation prevention. After digging deeper, I found that my fix only hides the real problem, which is not handling all cases in continuation packets.

There are basically 3 cases:
CASE 1: No Annex B found - the whole packet is a continuation of the previous one
CASE 2: Annex B found somewhere in the middle -the first part belongs to the previous NAL, the second part is a new NAL (timestamp needs to be updated)
CASE 3 (rare): The continuation packet starts directly with Annex B (timestamp needs to be updated)

I’ve updated my commit so it should handle all cases. It probably needs some testing, but in my scenarios it still works as expected.

Btw: I’m okay with publishing my code under the "Unlicense" license.