Fix PTS rollover detection using per-stream state instead of shared s…

[Aman-Cool]

[FIX] Fix PTS rollover detection using per-stream state instead of shared static

In raising this pull request, I confirm the following:

• I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md).
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.
• I have mentioned this change in the [changelog](https://github.com/CCExtractor/ccextractor/blob/master/docs/CHANGES.TXT).

My familiarity with the project is as follows (check one):

• I have never used CCExtractor.
• I have used CCExtractor just a couple of times.
• I absolutely love CCExtractor, but have not contributed previously.
• I am an active contributor to CCExtractor.

---

read_video_pes_header() used a static local variable (current_pts_33) to track the previous PTS for rollover detection. Since it's static, it was shared across all PIDs and across all input files in a batch run.

When file 1 ends with a high PTS (top bits = 7) and file 2 starts fresh with a low PTS, the rollover detector incorrectly treats this as a legitimate wrap and increments rollover_bits. Every subtitle in file 2 then gets its timestamp shifted forward by ~26.5 hours. CCExtractor exits 0, the output file looks valid, but all timestamps are completely wrong.

Fixed by moving current_pts_33 into demuxer_data as prev_pts_33 so each stream independently tracks its own previous PTS. 3 files, 5 lines changed. No logic changes.

[Aman-Cool]

Hey @cfsmp3 ,This fixes a silent bug where batch-processing multiple TS files could shift all subtitle timestamps in file 2 by ~26.5 hours due to a static variable being shared across streams. The fix is small; 3 files, 5 lines, just moving that state into the per-stream struct where it belongs.

Verified the bug in the actual source, confirmed it compiles clean, and updated the changelog before opening this. Happy to make changes if anything needs adjusting!

[ccextractor-bot]

CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit 6f7ce27...:

Report Name	Tests Passed
Broken	13/13
CEA-708	14/14
DVB	6/7
DVD	3/3
DVR-MS	2/2
General	25/27
Hardsubx	1/1
Hauppage	3/3
MP4	3/3
NoCC	10/10
Options	81/86
Teletext	21/21
WTV	13/13
XDS	34/34

Your PR breaks these cases:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2...
• ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65...
• ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b...
• ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...

Congratulations: Merging this PR would fix the following tests:

• ccextractor --out=spupng c83f765c66..., Last passed: Never

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.