Opened 2 days ago
Last modified 28 hours ago
#11080 new defect
FFmpeg timestamps do not consistently agree with packet timestamps
| Reported by: | markfilipak | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | undetermined |
| Version: | unspecified | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description (last modified by )
Summary of the bug:
I made a 4 second clip having 97 actual frames. Physical order is DTS.
VLC and PowerDVD play the clip perfectly.
'-f framecrc' & packet analyzer agree: 97 frames, same DTSes & PTSes.
'-vf showinfo' disagrees: 53 frames, a gap, and duplicates.
'-show_frames' disagrees: 53 frames, a different gap, and different duplicates.
'-vf showinfo' & '-show_frames' disagree substantially.
Other effects:
MPV exhibits a 2 second glitch that matches the gap.
'-ss' and '-to' exhibit the same sorts of problems.
__packet analyzer__ _____framecrc______ ___showinfo___ ______show_frames_______
(physical order) (DTS order) (DTS order) (DTS order)
___DTS___ ___PTS___ ___DTS___ ___PTS___ PN ___PTS___ DN ___DTS___ ___PTS___
504133642 504137396 504133642 504137396 0 504137396 I
504137396 504148657 504137396 504148657 3 504148657 P
504141150 504141150 504141150 1 504141150 all these PTSes = DTSes - 3 frames
504144903 504144903 504144903 2 504144903 ¦
504148657 504156165 504148657 504156165 5 504156165 P 0 504148657 504137396 I
504152411 504152411 504152411 4 504152411 1 504152411 504141150
504156165 504167426 504156165 504167426 8 504167426 P 2 504156165 504144903
504159918 504159918 504159918 6 504159918 3 504159918 504148657 P
504163672 504163672 504163672 7 504163672 4 504163672 504152411
504167426 504174933 504167426 504174933 10 504174933 P 5 504167426 504156165 P
504171180 504171180 504171180 9 504171180 6 504171180 504159918
504174933 504186195 504174933 504186195 13 504186195 P 7 504174933 504163672
504178687 504178687 504178687 11 504178687 8 504178687 504167426 P?
504182441 504182441 504182441 12 504182441 9 504182441 504171180
504186195 504197456 504186195 504197456 16 504197456 P 10 504186195 504174933 P
504189948 504189948 504189948 14 504189948 11 504189948 504178687
504193702 504193702 504193702 15 504193702 12 504193702 504182441
===== MPV time pauses here momentarily, then jumps 3 frames later =====
504197456 504204963 504197456 504204963 18 504204963 P 13 504197456 504186195 P
504201210 504201210 504201210 17 504201210 14 504201210 504189948
504204963 504216225 504204963 504216225 15 504204963 504193702
===== MPV time jumps from here =====
504208717 504208717 504208717 19 504208717 16 504208717 504197456 P?
504212471 504212471 504212471 20 504212471 17 504212471 504201210
504216225 504223732 504216225 504223732 18 504216225 504204963 P
504219978 504219978 504219978 19 504219978 504208717
===================== SPLICE HERE ======================
504223731 504227485 504223731 504227485
504227485 504234993 504227485 504234993
504231239 504231239 504231239
504234993 504246254 504234993 504246254
504238746 504238746 504238746
504242500 504242500 504242500
504246254 504257515 504246254 504257515
504250008 504250008 504250008
504253761 504253761 504253761
504257515 504265023 504257515 504265023
504261269 504261269 504261269
504265023 504276284 504265023 504276284
504268776 504268776 504268776
504272530 504272530 504272530
504276284 504287545 504276284 504287545
504280038 504280038 504280038
504283791 504283791 504283791
504287545 504295053 504287545 504295053
504291299 504291299 504291299
504295053 504306314 504295053 504306314
504298806 504298806 504298806
504302560 504302560 504302560
504306314 504317575 504306314 504317575
504310068 504310068 504310068
504313821 504313821 504313821
504317575 504325083 504317575 504325083
504321329 504321329 504321329
504325083 504332590 504325083 504332590
504328836 504328836 504328836
504332590 504340098 504332590 504340098
504336344 504336344 504336344
504340098 504347605 504340098 504347605
504343851 504343851 504343851
504347605 504355113 504347605 504355113
504351359 504351359 504351359
504355113 504362620 504355113 504362620
504358866 504358866 504358866
504362620 504370128 504362620 504370128
504366374 504366374 504366374
504370128 504377635 504370128 504377635
504373881 504373881 504373881
504377635 504385143 504377635 504385143
504381389 504381389 504381389
504385143 504396404 504385143 504396404 22 504396404 P 20 504385143 504212471
===== MPV time jumps to here =====
504388896 504388896 504388896
504392650 504392650 504392650 21 504392650 21 504392650 504392650 --+ best_effort_timestamp
504396404 504407665 504396404 504407665 25 504407665 22 504396404 504216225 P? ¦ switches
504400158 504400158 504400158 23 504400158 P 23 504400158 504396404 P ¦ from
504403911 504403911 504403911 24 504403911 24 504403911 504219978 ¦ 'pts'
504407665 504418926 504407665 504418926 28 504418926 I 25 504407665 504400158 ¦ to
504411419 504411419 504411419 26 504411419 I? 26 504411419 504223732 I ¦ 'pkt_dts'
504415173 504415173 504415173 27 504415173 27 504415173 504403911 ¦ here
504418926 504426434 504418926 504426434 30 504426434 28 504418926 504407665 I ¦
504422680 504422680 504422680 29 504422680 29 504422680 504411419 ¦
504426434 504433941 504426434 504433941 32 504433941 30 504426434 504415173 ¦
504430188 504430188 504430188 31 504430188 P 31 504430188 504418926 P ¦
504433941 504445203 504433941 504445203 35 504445203 P 32 504433941 504422680 ¦
504437695 504437695 504437695 33 504437695 P? 33 504437695 504426434 P ¦
504441449 504441449 504441449 34 504441449 34 504441449 504430188 ¦
504445203 504456464 504445203 504456464 38 504456464 P 35 504445203 504433941 P ¦
504448956 504448956 504448956 36 504448956 36 504448956 504437695 ¦
504452710 504452710 504452710 37 504452710 37 504452710 504441449 ¦
504456464 504467725 504456464 504467725 41 504467725 P 38 504456464 504445203 P ¦
504460218 504460218 504460218 39 504460218 39 504460218 504448956 ¦
504463971 504463971 504463971 40 504463971 40 504463971 504452710 ¦
504467725 504475233 504467725 504475233 43 504475233 41 504467725 504456464 P ¦
504471479 504471479 504471479 42 504471479 42 504471479 504460218 ¦
504475233 504486494 504475233 504486494 46 504486494 P 43 504475233 504463971 ¦
504478986 504478986 504478986 44 504478986 P? 44 504478986 504467725 P? ¦
504482740 504482740 504482740 45 504482740 45 504482740 504471479 ¦
504486494 504497755 504486494 504497755 52 504497755 I 46 504486494 504475233 P? ¦
504490248 504490248 504490248 47 504490248 47 504490248 504478986 ¦
504494001 504494001 504494001 48 504494001 48 504494001 504482740 --+
duplicate of 46 -> 49 504486494 P 49 "N/A" 504486494 P
duplicate of 47 -> 50 504490248 50 "N/A" 504490248
duplicate of 48 -> 51 504494001 51 "N/A" 504494001
52 "N/A" 504497755 I
How to reproduce:
ffmpeg -i Ticket_11080.m2ts -map 0 -copyts -c copy -dn -sn -f framecrc - >Ticket_11080.m2ts_framecrc.txt
ffmpeg -copyts -i Ticket_11080.m2ts -map 0:v -vf showinfo -c:v rawvideo -f null -muxdelay 0 - 2>Ticket_11080.m2ts_showinfo.txt
ffprobe -sexagesimal -select_streams v -show_frames -of flat -i Ticket_11080.m2ts >Ticket_11080.m2ts_show_frames.txt
[note]
ffmpeg version 2024-05-20-git-127ded5078-full_build-www.gyan.dev
[note] show_frames complains:
[null @ 000000000488bc40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 134397 >= 134395
[null @ 000000000488bc40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 134397 >= 134396
[null @ 000000000488bc40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 134397 >= 134397
What 134397 is, is unknown. It is not a DTS or PTS or packet number (packet numbers are 0..73599).
Change History (36)
comment:1 by , 2 days ago
| Description: | modified (diff) |
|---|---|
| Summary: | FFmpeg timestamps do not consistenly agree with packet timestamps → FFmpeg timestamps do not consistently agree with packet timestamps |
comment:2 by , 2 days ago
comment:3 by , 2 days ago
I don't know where to upload Ticket_11080.m2ts.
Never mind. I found it in the FFmpeg docs.
follow-up: 5 comment:4 by , 2 days ago
https://streams.videolan.org/upload/
Select ffmpeg, input ticket, upload.
Sample should then be here https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket11080
comment:6 by , 2 days ago
| Description: | modified (diff) |
|---|
comment:8 by , 2 days ago
Replying to Balling:
It will when you will upload the file.
I did, and got "Upload complete". I'll try it again.
follow-up: 11 comment:10 by , 2 days ago
If you can't get it to upload to videolan - Upload it to a free 3rd party hosting site (eg. google drive, sendspace, mediafire, dropbox, workupload etc...), post the url, and a developer will mirror it on ffmpeg trac / videolan for this ticket
comment:11 by , 2 days ago
comment:12 by , 2 days ago
By the way, earlier today I sent the video to Fereidoon Khosravi, SVP of Market Development for Venera. If he follows through, Venera technicians are going to validate it with Venera Pulsar. He also promised to give me a license for Pulsar. I wouldn't count on either actually happening. We shall see.
follow-ups: 16 17 18 19 comment:13 by , 2 days ago
You moved the first two B frames (their display), so that made decoding of GOP impossible so it prints "co located POCs unavailable" right on the 2nd frame (and the frame has artefacts), try to use mpv on your file and step forward 1 frame with . button. Well, and also this again starts with non-IDR I frame.
Again, Open GOP looks like this:
https://forum.videohelp.com/images/imgfiles/Df6d4pR.jpg
Open GOP needs to start with two B frames, yours starts with an I frame that is wrong.
follow-ups: 20 29 comment:14 by , 2 days ago
Ticket_11080.m2ts is the same problem as ticket #11055 - not a valid stream
Not cut/appended on IDR boundaries, no IDR pictures , decreasing frame_num and decreasing POC violations in coded stream order
eg.
Notice frame_num drops from 243 to 191
There is a free online viewer; you can demux to elementary stream and upload
VTCLab Media Analyzer
https://media-analyzer.pro/app
hex
00002f7139 frame_num 243 (0xF3)
00003938a0 frame_num 191 (0xBF)
If you examine a retail open GOP BD, the frame_num increases with each coded picture including non-IDR "i" frames, until the next IDR where it resets to zero as per the h264 specs .
"The value of frame_num is constrained as follows:
– If the current picture is an IDR picture, frame_num shall be equal to 0."
When you stream copy & append segment the slice header frame_num , POC entries are retained from original stream. In Ticket_11080.m2ts, the latter appended section is closer in coded order to it's own IDR picture, so has a lower frame_num. When you join, there is now a decrease in frame_num - this is a spec violation
Either that section from <IDR> to the <frame before next IDR> from your original source stream has to be re-encoded before appending stream copied segments - so the values frame_num and POC values reset and follow specs (then you can also get frame accurate cuts) - this is what "smart rendering" software does - or you live with IDR boundaries and "coarse" edits (some open GOP BD's can have hundreds of frames before the next IDR)
follow-up: 34 comment:15 by , 2 days ago
This stream is even worse, pdr0, as it has PTS of zero on I frame, but two first B frames should have smaller PTS, as they are presented before I frame and since they cannot be fully decoded actually are just dropped, and are later used for decoding of another, third, B frame. LOL
Also VLC really fails with this stream it has horrible artefacts.
Also, why is 42 actual presented frame is frame 10 in encoded mode (lets say 10/42) and that B frame depends on P frame 6/8 and P frame 9/45? That is crazy.
comment:16 by , 41 hours ago
I'm responding in the order your comments are in...
Replying to Balling:
You moved the first two B frames (their display),
I didn't move the first 2 B-frames, I dropped them because they are in the previous GOP. Here's the script:
: Cutting out a 4 second clip at the splice +/- 2 seconds. : : source is 00305+00306.m2ts : CUT1 = 1:32:49.814 = 5569.814 sec //running time to starting I-frame : CUT2 = 1:32:53.818 = 5573.818 sec //running time to ending I-frame : : CUT1: : (5569.814 sec)*(24/1.001 frames/sec) = 133542 frames : (2854113 ticks)+(133542 frames)*(3753.75 ticks/frame) = 504137395.5 ticks : = 504137396 ticks : PTS 504137396 is an I-frame in packet 75943446 : : step 1: ..________drop________ : \ : PTS order ..P B B I.. : ___________________________/ : / : DTS order I B B P.. : \ \ \ \ : 504126135 504129888 504133642 504137396 set CUT1=lt(pts\,504137396) : step 2: rewrite the I-frame's DTS : : PTS order I.. : _______/ : / : DTS order I P.. : \ \ : 504133642 504137396 set IDR=if(eq(DTS\,504126135)\,504133642,DTS) : CUT2: : (5573.818 sec)*(24/1.001 frames/sec) = 133638 frames : (2854113 ticks)+(133638 frames)*(3753.75 ticks/frame) = 504497755.5 ticks : = 504497755 ticks : PTS 504497755 is an I-frame in packet 76021654 : : PTS order ..P B B I : ___________________________/ ________drop________.. : / / : DTS order ..I B B P B B.. : \ \ \ \ : 504486494 504490248 504494001 504497755 set CUT2=gt(pts\,504497755) ffmpeg -copyts -i "c:\00305+00306.m2ts" -map 0 -bsf noise=drop='%CUT1%+%CUT2%',setts=dts='%IDR%':pts=PTS -c copy -sn -dn -muxdelay 0 "c:\Ticket_11080.m2ts" pause
Oh, look. DVBinspector is getting the running time wrong:
"pts: 0x1E0C86B4 (504137396) => 1:33:21.5266"
should be:
504137396-2854113 = (501283283 ticks)/(90000 ticks/sec) => 1:32:49.8142[5..]
DVBinspector isn't subtracting the initial PTS. The initial PTS has no relevance to actual frames.
I will comment on the rest in my next comment.
comment:17 by , 40 hours ago
Replying to Balling:
You moved the first two B frames (their display) [refuted in the previous comment], so that made decoding of GOP impossible so it prints "co located POCs unavailable"
Only 'ffprobe -show_frames' says "co located POCs unavailable". I think that's because the bug is affecting decoding. 'ffmpeg -f framecrc' does not decode, so it's unaffected by the bug. That's why 'ffmpeg -f framecrc' gives correct timestamps that match the actual packets.
Look at the actual packets, please.
Look, I know it is hard for you to accept that FFmpeg's timestamps are wrong. You're using FFmpeg functions to 'prove' things. I'm using the actual packets. That's physical evidence.
You think the 2 B-frames are part of the right-side GOP. I think they're part of the left-side GOP that gets cut off. Let me ask you this: Why would dropping the 2 B-frames make any difference at all? Whether they're part of the left-side GOP or the right-side GOP, why would dropping them make a difference?
I think this is a very old bug.
follow-up: 23 comment:18 by , 40 hours ago
Replying to Balling:
... Well, and also this again starts with non-IDR I frame.
I'm making the start frame (i.e., the I-frame) IDR. How can it be otherwise? It's the first frame!
comment:19 by , 40 hours ago
Again, Open GOP looks like this:
https://forum.videohelp.com/images/imgfiles/Df6d4pR.jpg
What is that? Is it authoritative?
Open GOP needs to start with two B frames, yours starts with an I frame that is wrong.
H.222, Quote: "After a GOP, the first picture shall be an I-picture". I believe it means "After a GOP header". I've never seen a GOP header that was followed by a B-frame in the same packet.
follow-up: 25 comment:20 by , 40 hours ago
Replying to pdr0:
Ticket_11080.m2ts is the same problem as ticket #11055 - not a valid stream
Not cut/appended on IDR boundaries, no IDR pictures , decreasing frame_num and decreasing POC violations in coded stream order
eg.
Notice frame_num drops from 243 to 191
The clip has only 97 frames.
Notice that frame_num applies to slices. Notice that H.264 says what to do with frame_num, but it never defines "frame_num".
comment:21 by , 40 hours ago
making the start frame (i.e., the I-frame) IDR. How can it be otherwise? It's the first frame!
IDR frames are nal_unit_type 5. Yours is 1.
comment:22 by , 40 hours ago
H.222, Quote: "After a GOP, the first picture shall be an I-picture"
That is true for H.222. Your file is H.264.
comment:23 by , 40 hours ago
Replying to markfilipak:
Replying to Balling:
... Well, and also this again starts with non-IDR I frame.
I'm making the start frame (i.e., the I-frame) IDR. How can it be otherwise? It's the first frame!
You cannot change the slice/frame type without re-encoding .
If it was IDR to begin with, frame_num would be "0". The first slice has a frame_num of 227 - hence it's a non-IDR slice. That alone makes it a non valid codec video sequence as per the ITU h.264 specs
G.3.18
"The first picture of each coded video sequence in decoding order is an IDR picture."
7.4.3
"The value of frame_num is constrained as follows:
– If the current picture is an IDR picture, frame_num shall be equal to 0."
follow-up: 26 comment:24 by , 40 hours ago
His source is Blu-ray, you cannot just quote the standard like this, it may be encoded using non-IDR frames throughout. Anyway, I think I need to show at least some proof: here Elecard 2023 shows that your first slice is actually non-IDR I frame. https://i.imgur.com/0V2RiWG.png (see it says nal_unit_type 1 (slice_layer_without_partitioning()))
The spec Table 7-1 says this is Coded slice of a non-IDR picture.
follow-up: 32 comment:25 by , 40 hours ago
Replying to markfilipak:
Replying to pdr0:
Ticket_11080.m2ts is the same problem as ticket #11055 - not a valid stream
Not cut/appended on IDR boundaries, no IDR pictures , decreasing frame_num and decreasing POC violations in coded stream order
eg.
Notice frame_num drops from 243 to 191
The clip has only 97 frames.
Notice that frame_num applies to slices. Notice that H.264 says what to do with frame_num, but it never defines "frame_num".
Yes, if you look at the parser there are 4 slices per frame (as per the BD specs) . The frame_num is wrong because it was improperly cut from a longer segment with more frames (slices), as described in ticket 11055 . Because there are no IDR frames or slices, there is no reset to frame_num and you get discontinunities
"frame_num is used as an identifier for pictures "
https://patents.google.com/patent/US20140064363A1/en
" For each reference picture in H.264, there is a codeword frame_num that acts as a label for the reference picture. The frame_num indicates the decoding order and the frame_num must increase by 1 for each reference picture in decoding order otherwise the bitstream is not compliant to the standard."
comment:26 by , 39 hours ago
Replying to Balling:
His source is Blu-ray, you cannot just quote the standard like this, it may be encoded using non-IDR frames throughout. Anyway, I think I need to show at least some proof: here Elecard 2023 shows that your first slice is actually non-IDR I frame. https://i.imgur.com/0V2RiWG.png (see it says nal_unit_type 1 (slice_layer_without_partitioning()))
Yes, but "encoded using non-IDR frames throughout" means there are IDR frames throughout as well . It is encoded with non-IDR throughout - The problem as mentioned before, and again in ticket 11055 is cuts/appends along non IDR boundaries
And the free analyzer I linked to above confirms the same thing as Elecard
https://media-analyzer.pro/app
nal_unit_type 1, 'Non-IDR Slice'
frame_num 227 (0xE3)
follow-up: 30 comment:27 by , 39 hours ago
means there are IDR frames throughout as well
No. It means there are none or maybe only in the beginning. You need to guess which frames are actually recovery.
comment:28 by , 39 hours ago
I dropped them because they are in the previous GOP.
No, the GOP starts with 2 B frames in coding order, they cannot be fully decoded, decode corrupt, which you can still see with ffmpeg -flags2 +showall -i "Ticket 11055.m2ts" cdasca.png
They are needed to decode frames after I frame. You cannot drop them.
comment:29 by , 39 hours ago
comment:30 by , 39 hours ago
Replying to Balling:
means there are IDR frames throughout as well
No. It means there are none or maybe only in the beginning. You need to guess which frames are actually recovery.
No , there are always many IDR frames in retail blu-ray
IDR frames are present at every chapter point at the miniumum. Have you ever looked at a retail blu-ray ?
As I mentioned earlier, some BD's have 100's of frames before the next IDR, but IDR's are always interspersed between non-IDR .
And you don't need to "guess" anything - that why I mentioned using stream analyzers such as Elecard in ticket 11055
comment:31 by , 39 hours ago
@markfilipak Well, please read this, I think proof about Open GOP starting with two B frames is proof enough. https://forum.doom9.org/showthread.php?t=182920 and
https://forum.doom9.org/showthread.php?t=185523
There are examples, where I frames follow other I frames... I mean clearly it is not as simple as in some papers. In some papers though it is mentioned that scene change can insert I frame.
follow-up: 36 comment:32 by , 38 hours ago
Replying to pdr0:
Replying to markfilipak:
Replying to pdr0:
Ticket_11080.m2ts is the same problem as ticket #11055 - not a valid stream
Not cut/appended on IDR boundaries, no IDR pictures , decreasing frame_num and decreasing POC violations in coded stream order
eg.
Notice frame_num drops from 243 to 191
The clip has only 97 frames.
Notice that frame_num applies to slices. Notice that H.264 says what to do with frame_num, but it never defines "frame_num".
Yes, if you look at the parser ...
You have a parser for MPEG2TS? Actual physical bits would help me to see what you're writing about. I write that because it seems to me you (or MPEG) are mixing stream frames, which have only timestamps and not frame numbers, with something that goes by frame numbers. I suspect they're actually frame offsets, not frame numbers. I suspect they're used for transforming slices between reference slices in other frames as opposed to transforming while frames. I suspect this has something to do with POC, which I find to be 'prescribed' rather than 'described', and so, seems rather vague and subject to interpretation.
Two things:
1 - If you have a parser for MPEG2TS, what is it? How do I get it? I can parse TS (as in MOV files) but not MPEG2TS.
2 - I have a proposal: Since this is going beyond a bug report and the time you are putting in is growing, how about I pay you? Money for instruction. That would only be fair to you and I'm willing to do it. If such instruction does reveal an actual bug, wonderful. If it doesn't that's fine too.
comment:33 by , 38 hours ago
Here is elecard 2023 basic. And what he is talking about is not about m2ts. Same result happens with Annex B bitstream. https://elecard-streameye.software.informer.com/download/#downloading
Only 'ffprobe -show_frames' says "co located POCs unavailable".
Fplay does too.
I can parse TS (as in MOV files)
Mov files are mp4.
comment:34 by , 38 hours ago
Replying to Balling:
This stream is even worse, pdr0, as it has PTS of zero on I frame ...
Huh? The first PTS is 504137396.
... but two first B frames should have smaller PTS, as they are presented before I frame and since they cannot be fully decoded actually are just dropped, and are later used for decoding of another, third, B frame. LOL
I think you're looking at Ticket_11055.m2ts. Look at Ticket_11080.m2ts -- I removed the 2 B-frames that were between I's DTS & PTS.
comment:35 by , 38 hours ago
Look at Ticket_11080.m2ts -- I removed the 2 B-frames that were between I's DTS & PTS.
And that is wrong. It was correct before that.
comment:36 by , 28 hours ago
Replying to markfilipak:
You have a parser for MPEG2TS? Actual physical bits would help me to see what you're writing about. I write that because it seems to me you (or MPEG) are mixing stream frames, which have only timestamps and not frame numbers, with something that goes by frame numbers. I suspect they're actually frame offsets, not frame numbers. I suspect they're used for transforming slices between reference slices in other frames as opposed to transforming while frames. I suspect this has something to do with POC, which I find to be 'prescribed' rather than 'described', and so, seems rather vague and subject to interpretation.
Stream parser like Stream Eye has been mentioned several times. It was first thing I mentioned in 11055 .
This link is from Iain E. Richardson's , “The H.264 Advanced Video Compression Standard” . It's a good book, and the author is a known expert
PLEASE READ! This explains frame_num and POC in simple terms
https://www.vcodex.com/h264avc-picture-management
In the simplest terms - Frame_num refers to decoding order . POC refers to the display order . Both frame_num and POC are found in the slice headers and refer to the actual h264 video stream, not something container specific like m2ts , ts, mp4, mkv etc... Frame_num has to increase by 1 every frame until the next IDR, POC does not . But if you get either frame_num or POC decreases, the stream does not conform to specifications .
The most common cause of decreases in frame_num or POC types of non conforming streams are.... you guessed it... bad cuts and appends. e.g. An "I" frame is mistaken for IDR
Both frame_num and POC reset to zero at each IDR. Since you have no IDR's you have wild frame_num (243) compared to the encoded frame count (97), because you are missing frames up to the previous IDR from the original stream. ie. your 1st "i" frame is frame 243 compared to it's own IDR (frame zero) in the original stream. The decrease in POC and frame_num are from the appended section, which was closer in proximity to it's own IDR (fewer missing frames, thus a lower value) . Thus, you must cut on IDR boundaries as explained earlier , or re-encode the affected section before joining if you needed frame accurate cuts. The re-encoded section places a new IDR, the frame_num and POC are reset to zero, and that section is a valid video sequence. (It's a bit more complicated than that, you generally have to encode using similar settings for a proper join, and if it was for authored BD, there are potential VBV issues)
2 - I have a proposal: Since this is going beyond a bug report and the time you are putting in is growing, how about I pay you? Money for instruction. That would only be fair to you and I'm willing to do it. If such instruction does reveal an actual bug, wonderful. If it doesn't that's fine too.
You want a teacher who intimately knows the specs. Sorry, that's not me.
Bottom line - Ticket_11055.m2ts, Ticket_11080.m2ts are invalid streams for the reasons previously posted. If you post a valid spec video sequence, and there are ffmpeg timestamp issues, then it should be investigated.
I will say that 1) there were problems like this before with 50 issues in https://github.com/google/ExoPlayer/issues/4951
2) there is such an issue in https://trac.ffmpeg.org/ticket/3705#comment:16 but that even does not have Recovery Point SEI.
3) there is an issue that should be fixed first in ffprobe: #8820 where even reencoding does not help, it breaks the decoder completly, yet playback works, also see sample in #3386 that also shows an issue in ffprobe
4) we are not as perfect in following standards as e.g. -vcodec h264_cuvid as an example #7374