Opened 2 weeks ago
Last modified 4 hours ago
#11055 reopened defect
OGOP (Open GOP) in certain conditions may cause missing frames of decoding
| Reported by: | markfilipak | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avcodec |
| Version: | git-master | Keywords: | everything OGOP |
| Cc: | MasterQuestionable | 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 99 actual frames. Physical order is DTS.
VLC and PowerDVD play the clip perfectly.
'-f framecrc' & packet analyzer agree: 99 frames, same DTSes & PTSes.
'-vf showinfo' disagree: 53 frames, gap & duplicates.
'-show_frames' disagree: 54 frames, gap & 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_______
(packet order) (DTS order) (DTS order) (DTS order)
___DTS___ ___PTS___ ___DTS___ ___PTS___ N ___PTS___ N ___DTS___ ___PTS___
504126135 504137396 504126135 504137396 0 504137396 I
504129888 504129888 504129888
504133642 504133642 504133642
504137396 504148657 504137396 504148657 3 504148657 P
504141150 504141150 504141150 1 504141150 B
504144903 504144903 504144903 2 504144903 B
504148657 504156165 504148657 504156165 5 504156165 P 0 504148657 504137396 I
504152411 504152411 504152411 4 504152411 B 1 504152411 504141150 B
504156165 504167426 504156165 504167426 8 504167426 P 2 504156165 504144903 B
504159918 504159918 504159918 6 504159918 B 3 504159918 504148657 P
504163672 504163672 504163672 7 504163672 B 4 504163672 504152411 B
504167426 504174933 504167426 504174933 10 504174933 P 5 504167426 504156165 P
504171180 504171180 504171180 9 504171180 B 6 504171180 504159918 B
504174933 504186195 504174933 504186195 13 504186195 P 7 504174933 504163672 B
504178687 504178687 504178687 11 504178687 B 8 504178687 504167426 P
504182441 504182441 504182441 12 504182441 B 9 504182441 504171180 B
504186195 504197456 504186195 504197456 16 504197456 P 10 504186195 504174933 P
504189948 504189948 504189948 14 504189948 B 11 504189948 504178687 B
504193702 504193702 504193702 15 504193702 B 12 504193702 504182441 B
504197456 504204963 504197456 504204963 18 504204963 P 13 504197456 504186195 P
504201210 504201210 504201210 17 504201210 B 14 504201210 504189948 B
504204963 504216225 504204963 504216225 15 504204963 504193702 B
504208717 504208717 504208717 19 504208717 B 16 504208717 504197456 P
504212471 504212471 504212471 20 504212471 B 17 504212471 504201210 B
504216225 504223732 504216225 504223732 18 504216225 504204963 P
504219978 504219978 504219978 19 504219978 504208717 B
===================== SPLICE HERE ====================== ¦
504223731 504227485 504223731 504227485 these DTSes = PTSes + 3 frames
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 these DTSes = PTSes + 3 frames
504381389 504381389 504381389 ¦
504385143 504396404 504385143 504396404 22 504396404 P 20 504385143 504212471 B
504388896 504388896 504388896
504392650 504392650 504392650 21 504392650 B 21 504392650 504392650 B --+ best_effort_timestamp
504396404 504407665 504396404 504407665 25 504407665 B 22 504396404 504216225 P ¦ switches
504400158 504400158 504400158 23 504400158 P 23 504400158 504396404 P ¦ from
504403911 504403911 504403911 24 504403911 B 24 504403911 504219978 B ¦ 'pts'
504407665 504418926 504407665 504418926 28 504418926 I 25 504407665 504400158 B ¦ to
504411419 504411419 504411419 26 504411419 I 26 504411419 504223732 I ¦ 'pkt_dts'
504415173 504415173 504415173 27 504415173 B 27 504415173 504403911 B ¦ here
504418926 504426434 504418926 504426434 30 504426434 B 28 504418926 504407665 I ¦
504422680 504422680 504422680 29 504422680 B 29 504422680 504411419 B ¦
504426434 504433941 504426434 504433941 32 504433941 B 30 504426434 504415173 B ¦
504430188 504430188 504430188 31 504430188 P 31 504430188 504418926 P ¦
504433941 504445203 504433941 504445203 35 504445203 P 32 504433941 504422680 B ¦
504437695 504437695 504437695 33 504437695 P 33 504437695 504426434 P ¦
504441449 504441449 504441449 34 504441449 B 34 504441449 504430188 B ¦
504445203 504456464 504445203 504456464 38 504456464 P 35 504445203 504433941 P ¦
504448956 504448956 504448956 36 504448956 B 36 504448956 504437695 B ¦
504452710 504452710 504452710 37 504452710 B 37 504452710 504441449 B ¦
504456464 504467725 504456464 504467725 41 504467725 P 38 504456464 504445203 P ¦
504460218 504460218 504460218 39 504460218 B 39 504460218 504448956 B ¦
504463971 504463971 504463971 40 504463971 B 40 504463971 504452710 B ¦
504467725 504475233 504467725 504475233 43 504475233 B 41 504467725 504456464 P ¦
504471479 504471479 504471479 42 504471479 B 42 504471479 504460218 B ¦
504475233 504486494 504475233 504486494 46 504486494 P 43 504475233 504463971 B ¦
504478986 504478986 504478986 44 504478986 P 44 504478986 504467725 P ¦
504482740 504482740 504482740 45 504482740 B 45 504482740 504471479 B ¦
504486494 504497755 504486494 504497755 52 504497755 I 46 504486494 504475233 P ¦
504490248 504490248 504490248 47 504490248 B 47 504490248 504478986 B ¦
504494001 504494001 504494001 48 504494001 B 48 504494001 504482740 B --+
repeat -> 49 504486494 P
repeat -> 50 504490248 B
repeat -> 51 504494001 B
49 "N/A" 504486494 P
50 "N/A" 504490248 B
51 "N/A" 504494001 B
52 "N/A" 504497755 I
How to reproduce:
ffmpeg -i Ticket_11055.m2ts -map 0 -copyts -c copy -an -dn -sn -f framecrc ->>Ticket_11055.m2ts_framecrc.txt
ffmpeg -copyts -i Ticket_11055.m2ts -map 0:v -vf showinfo -c:v rawvideo -f null -muxdelay 0 - 2>>Ticket_11055.m2ts_showinfo.txt"
ffprobe -sexagesimal -select_streams v -show_frames -of flat -i Ticket_11055.m2ts
ffmpeg version 2024-05-20-git-127ded5078-full_build-www.gyan.dev
Attachments (4)
Change History (211)
comment:1 by , 2 weeks ago
comment:2 by , 2 weeks ago
| Cc: | added |
|---|---|
| Component: | undetermined → avfilter |
| Keywords: | showinfo show_frames added |
| Summary: | framecrc: correct PTSes; showinfo: bad PTSes & more... → "showinfo", "-show_frames": bad PTS; where "framecrc" had expected; plus inconsistent playback |
| Version: | unspecified → git-master |
͏ "best_effort_timestamp" appears to be mere...
͏ ( exist ${pkt_dts} ? ${pkt_dts} : ${pts} )
͏ ; from Frame #22 onward.
͏ See:
͏ comment:72 for more sensible table.
͏ comment:112 for how "Ticket_11055.m2ts" was generated.
͏ ----
͏ Not everyone may be good at deciphering Windows Batch/CMD.
͏ Try the description here?..
͏ https://trac.ffmpeg.org/attachment/ticket/11052/sample.mp4.xml
͏ Appears whereunder:
͏ https://streams.videolan.org/ffmpeg/incoming/11055/
͏ <&Strikeout>Judging from the file size I suppose the media is uncompressed.
͏ Try archive it with LZMA in 7z:
͏ |*| Compression level: 9 - Ultra ("x=9")
͏ |*| Word size: 273 ("fb=273")
͏ .
͏ See also: https://documentation.help/7-Zip/method.htm#SevenZipX
͏ Or just zipping it anyhow...</&>
<.> Probably wouldn't help for this case.
͏ What's the video resolution?
͏ See: https://trac.ffmpeg.org/attachment/ticket/11055/Ticket_11055.m2ts.xml
͏ Further compressing ͏"Ticket_11055.m2ts" may attain ~ 75% compression ratio.
͏ (ZIP Deflate, or 7z LZMA: both close, LZMA slightly smaller)
͏ ----
͏ Selected debug summary:
[[
[ pdr0 @ CE 2024-06-27 13:11:40 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:184
͏ "Ticket_11055.m2ts" is not a valid coded video sequence, because it has no IDR picture.
͏ FFprobe/FFmpeg often misidentifies non-key "i" as IDR.
͏ All entries of `ffprobe -show_frames` "key_frame=1" on this sample are wrong.
͏ .
͏ You can verify with a stream analyzer tool, such as: Elecard StreamEye, CodecVisa.
͏ A free way to verify IDR frames (in display order) with Nvidia graphics card is DGIndexNV: the DGI output is Plain Text.
͏ Whose IDR identification results corresponded to professional stream analyzers' results.
͏ There are "frame_num", POC (Picture Order Count) violations - likely errors in processing from misidentification of improperly cut GOP. ]
͏----
[ MasterQuestionable @ CE 2024-06-27 21:19:20 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:186
͏ As for FF-series tools' misidentification, would it because the peculiarity of this file:
͏ That caused FF-* to practically regard all alike "i" as "I"?
͏ Context of comment:185:
͏ https://stackoverflow.com/questions/75635925
͏ https://trac.ffmpeg.org/ticket/5309#comment:16 ]
͏----
[ pdr0 @ CE 2024-06-27 22:20:23 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:188
͏ "Is not there a recovery point at the start? Elecard 2023 says so."
<^> Yes, but it's still not a valid sequence per the ITU H.264 specs.
͏ ...
͏ As for the other issues:
͏ E.g.
͏ |*| The 1st frame in coded order specifies a "frame_num" of 227
͏ |*| And "pic_order_count_lsb" as 362 in this 99 frames sample...
͏ Another issue is the values are supposed to increase in decoding order, according to the specs. But there are examples where they decrease.
͏ This might be contributing to some of the problems observed with FFmpeg timestamps. ]
͏----
[ pdr0 @ CE 2024-06-28 15:46:11 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:192
͏ ...
͏ Why only 97 frames? I believe it's the way FFmpeg handles missing information.
͏ The 1st 2 frames in display order are missing information; and are dropped by FFmpeg:
͏ Some applications place duplicates for those error frames, others drop them - it's application dependent.
͏ The NVDEC decoder itself returns 99 frames.
͏ E.g. If you use L-SMASH's `decoder="h264_cuvid"`, or DGDecNV with AviSynth or VapourSynth: the 2 error frames are kept as duplicate placeholder frames.
͏ Frame count has sync implications when you cut/append streams.
͏ But those errors shouldn't be there in the first place: had the stream processed properly. ]
͏----
[ Balling @ CE 2024-06-29 20:13:14 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:203
͏ Keyframes are specific I-frames.
͏ Keyframes are only when you clean start from it. (IDR frame)
͏ In Open GOP, by definition you can have a situation:
͏ Where some after I-frames or its slices, you can have dependence on frames before that I-frame:
͏ Thus that is non-IDR frame/slice.
͏ Moreover, some frames can still be cleanly decoded even though we have that.
͏ And are marked as recovery frames with "exact_match=1" like in your example.
͏ Moreover, some frames are tagged as just recovery: that allows to get after some frames to the same stream.
͏ See, for example: https://bitmovin.com/vvc-open-gop-resolution-switching ]
]]
comment:3 by , 2 weeks ago
| Summary: | "showinfo", "-show_frames": bad PTS; where "framecrc" had expected; plus inconsistent playback → "showinfo", "-show_frames": bad PTS, where "framecrc" had expected; plus inconsistent playback |
|---|
͏ Also what "packet analyzer"?
comment:4 by , 2 weeks ago
It's called "MPEG-2 TS Packet Analyzer". It's not really a packet analyzer. It's just a packet browser -- it doesn't do any analysis. It's pretty primitive, though it does show PESes (and only PESes, including DTS & PTS).
The point is, the packet analyzer and framecrc agree. showinfo and show_frames disagree with them and with each other. That indicates a problem deep inside FFmpeg, not only with showinfo and show_frames. That MPV also screws up is a clue. I assume MPV is accessing FFmpeg via 'C' calls.
comment:5 by , 2 weeks ago
͏ I understand. As I have expected.
͏ However FFmpeg shouldn't be the primary target of blame.
comment:6 by , 2 weeks ago
showinfo disagrees with framecrc. What more is there to say?
show_frames disagrees with framecrc. What more is there to say?
showinfo and show_frames disagree with one another. What more is there to say?
The so-called packet analyzer -- the first hit with Google -- confirms that framecrc is correct. What more is there to say?
follow-up: 28 comment:7 by , 2 weeks ago
I can't parse M2TSes. So, I don't know if there's something else that's tripping up FFmpeg. For example, there may be something is M2TS having to do with sequence header that's not in VOBs.
comment:8 by , 2 weeks ago
May I point out that show_frames is saying DTS>PTS?
Look carefully. Thanks.
comment:9 by , 2 weeks ago
How many times have you seen "discontinuous DTS"? How many times have you seen '-ss' and '-to' trims lead to bad concatenations? I don't get those anymore, but my procedure is very tedious. It would be nice is '-ss' and '-to' worked properly. What I have supplied is a 4 second splice out of 4 episodes with 7 trims and 3 concatenations of a 5 hour episodic video. Everything I've done via workarounds are perfect and I've proceeded with HEVC transcoding and MP4 packaging. I've submitted this bug report as a good citizen and in hopes that trimming and concatenations will get better. My video episodes are all open GOP.
comment:10 by , 2 weeks ago
Sorry about the Windows cmd lines. Here's the important commands without the Windows stuff:
ffmpeg -i %1 -map 0 -copyts -c copy -an -dn -sn -f framecrc -
ffmpeg -copyts -analyzeduration 240000000 -probesize 1000000000 -i %1 -map 0:v -copyts -vf showinfo -c:v rawvideo -f null -muxdelay 0 -
ffprobe -sexagesimal -analyzeduration 240000000 -probesize 1000000000 -select_streams v -show_frames -of flat -i %1
comment:11 by , 2 weeks ago
͏ Thanks.
͏ Part of the reasons come from the relevant standards illy-defined:
͏ That essentially had everyone confused and everything screwed-up.
͏ Partly related: https://trac.ffmpeg.org/ticket/11034#comment:1
͏ [ ^ Yet incomplete. Through review planned later. ]
comment:12 by , 2 weeks ago
May I also point out that show_frames is reporting DTSes for B-frames. Of course, B-frames don't have DTSes. May I also point out that show_frames shows many of the B-frames having DTSes and PTSes that don't match. I don't know how show_frames is creating B-frame DTSes, but whatever it's doing, it's wrong.
comment:13 by , 2 weeks ago
| Component: | avfilter → undetermined |
|---|---|
| Keywords: | vf_showinfo ffprobe -show_frames added; showinfo show_frames removed |
comment:14 by , 2 weeks ago
@MasterQuestionable, Thank you for triage and for taking this seriously. I think it is a very, very important bug that affects a great many FFmpeg functions, including '-ss' and '-to' and outside applications like MPV. I will take a break now after 2 months of work on this.
comment:15 by , 2 weeks ago
͏ Affects far more than FFmpeg.
͏ Regardless, I may not be able to actively follow-up whatsoever.
͏ (have other tasks of priority, regardless)
͏ Technically DTS (Decoding Timestamps) shall be run-time decided.
͏ And shouldn't (also couldn't) be of concern before when.
͏ Somewhat explained in:
͏ https://github.com/MasterInQuestion/talk/discussions/3#discussion-5219034
follow-up: 85 comment:16 by , 2 weeks ago
͏ “... "-show_frames" shows many of the B-frames having DTS and PTS that don't match.”
<^> B-frame by definition won't have identical DTS and PTS.
͏ I-frame: Keyframe independently decodable.
͏ P-frame: Frame may refer arbitrary previous frames.
͏ B-frame: Frame may refer arbitrary next/previous frames. (both quantity, directionality)
͏ Comparable analogy of B-frame... comment:82
͏ Less complex: comment:98
comment:17 by , 2 weeks ago
| Keywords: | OGOP added |
|---|
͏ This could be alternatively summarized as Open GOP havoc.
͏ (see [ https://trac.ffmpeg.org/ticket/5309#comment:16 ] for more info)
comment:18 by , 2 weeks ago
@MasterQuestionable,
I don't understand your comments.
"B-frame by definition won't have identical DTS and PTS."
By definition? B-frames do not have DTSes at all.
comment:20 by , 2 weeks ago
I assume you mean something like this: "at what time are B-frames fetched for decoding and what is the decode time for B-frames?"
I have no idea. But I do know that PES header -> PTS_DTS_flags = 10 for all the B-frames I've ever seen. You undoubtedly know that, too, so, I don't know what your comment means.
comment:21 by , 2 weeks ago
͏ As mentioned in:
͏ https://github.com/MasterInQuestion/talk/discussions/3#issuecomment-1546859236
͏ The description is not capped by arbitrary implementations: but theoretical functionality.
͏ So horribly defined... they are:
͏ https://en.wikipedia.org/wiki/Packetized_elementary_stream#Optional_PES_header
comment:22 by , 2 weeks ago
H.222, 2.4.3.7
"PTS_DTS_flags – This is a 2-bit field. When the PTS_DTS_flags field is set to '10', the PTS fields shall be present in the PES packet header. When the PTS_DTS_flags field is set to '11', both the PTS fields and DTS fields shall be present in the PES packet header. When the PTS_DTS_flags field is set to '00' no PTS or DTS fields shall be present in the PES packet header. The value '01' is forbidden."
I've never seen a B-frame having PTS_DTS_flags = '11'.
follow-up: 24 comment:23 by , 2 weeks ago
͏ Implementations may optionally ignore it for its uselessness.
comment:24 by , 2 weeks ago
Replying to MasterQuestionable:
͏ Implementations may optionally ignore it for its uselessness.
Implementations may optionally ignore ...what?
Ignore the MPEG 'PTS_DTS_flags' tag? I don't think so.
What is useless?
follow-up: 26 comment:25 by , 2 weeks ago
͏ As you have noted: it serves no actual purpose.
͏ (mostly just pointless bytes)
͏ "it", may mean many things.
comment:26 by , 2 weeks ago
Replying to MasterQuestionable:
͏ As you have noted: it serves no actual purpose.
͏ (mostly just pointless bytes)
͏ "it", may mean many things.
What _are_ you 'talking' about?
comment:28 by , 2 weeks ago
Replying to markfilipak:
I can't parse M2TSes. So, I don't know if there's something else that's tripping up FFmpeg. For example, there may be something is M2TS having to do with sequence header that's not in VOBs.
I guess there is 'something else'.
I discovered this: "co located POCs unavailable" while transcoding (AVC->HEVC) and remuxing (M2TS->MP4). POCs are particular to H.264.
Of course, it has no bearing on why framecrc, showinfo, and show_frames differ.
I read about POCs in H.264. I think there might be an effect on DTSes & PTSes. Can you help me out with this?
comment:29 by , 2 weeks ago
Am I correct in understanding that "POCs" here refers to "Picture Order Count" as described in e.g. https://www.vcodex.com/h264avc-picture-management/ ? Or is it some other acronym?
I don't know H.264 format very well. It may be that anyone who knows H.264 well enough to help diagnose this ticket might also know what you mean by POC. Sometimes, however, less expert people read bug reports and might even make contributions, and I would like to help them (and me) follow along.
comment:30 by , 2 weeks ago
͏ Mostly yes.
͏ https://www.google.com/search?hl=en&gl=ca&num=10&q=AVC|H.264|H264+%22POC%22
͏ "POC" tends to be more commonly used as "Proof of Concept" generally.
͏ ("PoC" preferred)
͏ More info: https://en.wiktionary.org/wiki/POC
comment:31 by , 2 weeks ago
Well, ffmpeg is not Proof of concept software, we are mature enough, and also we do not leave exploits's pos in the code. So it is a different POC. :)
Physical order is DTS.
Why do you have to clarify this? Containers require DTS to be strict mnotonic. Otherwise always a bug.
comment:32 by , 2 weeks ago
They would appear here https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket11055
follow-up: 37 comment:33 by , 2 weeks ago
B-frames do not have DTSes at all.
That is WRONG. In fact only mkv will not have dts, as it does not have them at all. I mean just check this out: B frames have DTS. In practice DTS is not needed, I agree, it must increase always.
Sample/frame 58, 59 and 60 are B-frames which actually depends on the
key frame (57). Here the key frame is not an IDR but a "CRA" (Clean
Random Access).
follow-up: 38 comment:34 by , 2 weeks ago
͏ Bad management and later dead link...
͏ ----
͏ I've been analyzing your file (͏"Ticket_11055.m2ts").
͏ The file seems problematic. (mostly on the video timestamps)
͏ Complete report later.
follow-up: 47 comment:35 by , 2 weeks ago
[Parsed_vfrdet_0 @ 00000296386eec80] VFR:0.557692 (29/23) min: -7507 max: 180179 avg: 9448 [null @ 0000029638591580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 95 >= 93 [null @ 0000029638591580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 95 >= 94 [null @ 0000029638591580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 95 >= 95
ffmpeg.exe -i "Ticket 11055.m2ts" -an -vf vfrdet -f null -
follow-up: 39 comment:36 by , 2 weeks ago
͏ "Physical order is DTS."
͏ It mostly just means the logical order in the file's arrangement, shall be the presentation order.
͏ (permissive parsing)
comment:37 by , 2 weeks ago
Replying to Balling:
B-frames do not have DTSes at all.
That is WRONG.
Do you agree that B-frames have MPEG tag 'PTS_DTS_flags' set to '10'?
I've never seen otherwise.
comment:38 by , 2 weeks ago
Replying to MasterQuestionable:
Huh? Replying to MasterQuestionaable?
͏ I've been analyzing your file (͏"Ticket_11055.m2ts").
͏ The file seems problematic. (mostly on the video timestamps)
͏ Complete report later.
Browse the packets and look at the PESes. Don't use FFmpeg or you'll see foo. I wasted weeks of work until I realized that FFmpeg was giving me bogus TSes. You can't use FFmpeg to test FFmpeg.
comment:39 by , 2 weeks ago
Replying to MasterQuestionable:
͏ "Physical order is DTS."
͏ It mostly just means the logical order in the file's arrangement, shall be the presentation order.
͏ (permissive parsing)
It means that as packet numbers increase, DTSes increase. It means that PTSes are out of order. Videos can be in DTS-order or PTs-order, MPEG doesn't specify.
follow-up: 42 comment:40 by , 2 weeks ago
͏ Pluralized acronym looks non-sense.
͏ Worst case:
͏ (SI time unit)
͏ s, ms | mses ses ...
͏ Pluralizing proper nouns tends to be problematic:
͏ Should "Williams" mean 1 Williams or several William..?
follow-up: 43 comment:41 by , 2 weeks ago
͏ Your explanation hardly links...
͏ So what should be the appropriate presentation order for this video?
͏ Did you mean that there would be ~ 2 s video frames ignored by "-show_frames" alike?
͏ Regardless, other parsers may not be as correct.
͏ Probably had to manually parse also verify the relevant codes...
͏ ----
͏ Needless to start pointless debates:
͏ It's merely this "DTS" != that "DTS"...
comment:42 by , 2 weeks ago
Replying to MasterQuestionable:
͏ Pluralized acronym looks non-sense.
͏ Worst case:
͏ (SI time unit)
͏ s, ms | mses ses ...
͏ Pluralizing proper nouns tends to be problematic:
͏ Should "Williams" mean 1 Williams or several William..?
The English standard is to pluralize words ending is 's' by adding 'es'. For example, "Williams" and "Williamses". Possessive: "Williams's" and "Williamses's". I didn't make it up. It's just the standard.
comment:43 by , 2 weeks ago
Replying to MasterQuestionable:
͏ Your explanation hardly links...
͏ So what should be the appropriate presentation order for this video?
I don't care. It is what it is. I don't think it matters. I didn't do anything to force DTS-order.
͏ Did you mean that there would be ~ 2 s video frames ignored by "-show_frames" alike?
No. It's as I showed in my submittal (at the top). I used a packet analyzer -- _not_ FFmpeg -- to determine what the true TSes are and I used the packet analyzer to determine that it was DTS-order.
comment:44 by , 2 weeks ago
About DTS-order versus PTS-order:
Most professional videos are PTS-order. Some are DTS-order. So far I haven't seen a video that flips back and forth, but it's possible because MPEG doesn't say it should not be done. So, if even a professional splices two videos together, I imagine the result could flip back and forth.
Edit: I believed what I read in several places written by people I thought were authorities. Now, I've checked about 2 dozen Blu-ray discs, myself. All were DTS-order. Sorry about the disinformation above.
comment:45 by , 2 weeks ago
Ahem! Have you noticed that show_frames shows DTS>PTS?
DTS-order versus PTS-order... PTSes and DTSes reversed... Does this suggest anything to you?
comment:46 by , 2 weeks ago
Actually, DTS-order is better because the packets/frames are in decoder load order and there's less buffering. MPEG didn't think about that.
comment:47 by , 2 weeks ago
Replying to Balling:
[Parsed_vfrdet_0 @ 00000296386eec80] VFR:0.557692 (29/23) min: -7507 max: 180179 avg: 9448 [null @ 0000029638591580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 95 >= 93 [null @ 0000029638591580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 95 >= 94 [null @ 0000029638591580] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 95 >= 95ffmpeg.exe -i "Ticket 11055.m2ts" -an -vf vfrdet -f null -
Hmmm... I've never used vfrdet. All my stuff is CFR. I think you've found another victim of this bug.
comment:48 by , 2 weeks ago
͏ Confusing counter-intuitive...
͏ Again another standard illy-defined. (1,048,576 Bs?!)
͏ Well while the DTS thing in fact shouldn't matter..?
͏ Validity is irrelevant of the speaker's identity.
͏ The very non-sense uttered by big names: remains non-sense.
͏ Without B-frames: decoding, presentation order can be unified.
͏ I noticed, though haven't yet publicized due to potential misinformation. (draft)
͏ The DTS are mostly (except the few near the ~ 2 s gap) ~ (( 3 * 1/23.98 ≈ 0.1251 )) s later than the PTS.
͏ However which may not be applicable involving B-frames:
͏ Imagining the 1st frame (to present) somehow has dependence on all later frames...
͏ How to decode?
͏ ----
͏ Timestamps wrong, of course everything thereafter broken.
͏ (VFR (Variable Frame Rate) detection)
͏ Note this exact frame rate (23.976 FPS) cannot be real CFR.
͏ E.g. https://trac.ffmpeg.org/attachment/ticket/11052/sample.mp4.xml
comment:49 by , 2 weeks ago
Well, this has come as a surprise to me: 48 comments already. Shall I summarize?
comment:51 by , 2 weeks ago
Replying to MasterQuestionable:
͏ Modifying the description preferable.
You seem to be getting the gist of the problem. What description do you suggest?
comment:52 by , 2 weeks ago
By the way, the mastering for the sources for my 4 two-ended trims and 3 splices is a Criterion Blu-ray. Does anyone want to question Criterion? ...just joking. :-)
comment:53 by , 2 weeks ago
͏ I suppose first wait me finished analyzing the video?
͏ Too much to question... bother not.
follow-up: 56 comment:55 by , 2 weeks ago
| Priority: | normal → important |
|---|
͏ Part of my research.
͏ Also, I'd like you to again confirm the frame count:
͏ "-show_frames" variant indicated (also in your table) 53 frames total.
comment:56 by , 2 weeks ago
Replying to MasterQuestionable:
͏ Part of my research.
͏ Also, I'd like you to again confirm the frame count:
͏ "-show_frames" variant indicated (also in your table) 53 frames total.
Yes, there are really 99 frames.
framecrc reports exactly the same 99 frames.
showinfo reports 53 frames that includes a gap & duplicates.
show_frames reports 54 frames that includes a slightly different gap and slightly different duplicates.
comment:57 by , 2 weeks ago
Note this exact frame rate (23.976 FPS) cannot be real CFR.
You are wrong. It is true for default mkv, but not for TS. Both 24/1.001 and 23976/1000 are reproduciable perfectly in MPEGTS.
comment:58 by , 2 weeks ago
͏ I counted your table and couldn't find Frame #54 of "-show_frames".
͏ (also not present in my `ffprobe` dump)
͏ ----
͏ Then `ffprobe` 's output must be again wrong... (see E.g. XML)
͏ Concerning actual playback experience: nothing can be absolutely CFR.
follow-ups: 60 68 comment:59 by , 2 weeks ago
LOL, your file is horrible, use state of the art software, it has bugs too though https://github.com/EricBerendsen/dvbinspector: 
comment:60 by , 2 weeks ago
Replying to Balling:
LOL, your file is horrible, use state of the art software, it has bugs too though
What is that? Was it made by FFmpeg?
comment:61 by , 2 weeks ago
https://github.com/EricBerendsen/dvbinspector is written in JAVA. SO NO. It has at least 1 bug ffmpeg has EVEN right now. Note that.
comment:62 by , 2 weeks ago
͏ The file ("Ticket_11055.m2ts") is indeed problematic.
͏ However perhaps some optimization on parsing such could be done.
͏ Note:
͏ Better lossless image compression accomplishable with WebP:
͏ https://github.com/MasterInQuestion/attach#readme
comment:64 by , 2 weeks ago
Oh, by the way -- this may be important -- I finished the transcode-remux from AVC-M2TS to HEVC-MP4. Whereas AVC-M2TS plays flawlessly in VLC and PowerDVD, HEVC-MP4 stalls at the 2nd splice in VLC for about 6 seconds, and it crashes PowerDVD immediately.
So it appears this bug has affected the transcode-remux.
I have shown you only the 1st splice. Would you like to see a chart for the 2nd splice?
While I made each splice, I checked the splice with the packet analyzer. In terms of DTSes & PTSes, all three splices are perfect. Since they are all open GOP, I carried over (into the splice) the I-frame that the open B-frames needed, but those I-frames only. The very next frame (on the 'other' side of the splice) is the 1st I-frame of the next episode.
comment:65 by , 2 weeks ago
One more thing. Below is the console output during the transcode-remux. FFmpeg did not complain except for "co located POCs unavailable". And there were 354 duplicate frames (14.76475 seconds) and 1 dropped frame.
G:\FANNY AND ALEXANDER [1982(1983)]>ffmpeg -i "g:\FANNY AND ALEXANDER [1982(1983)]\FANNY AND ALEXANDER [1982(1983)].m2ts" -map 0 -c:a copy -c:v libx265 -x265-params crf=18 -dn "e:\Movies4\FANNY AND ALEXANDER [1982(1983)].mp4"
ffmpeg version 2024-05-20-git-127ded5078-full_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 13.2.0 (Rev5, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 59. 19.100 / 59. 19.100
libavcodec 61. 5.104 / 61. 5.104
libavformat 61. 3.103 / 61. 3.103
libavdevice 61. 2.100 / 61. 2.100
libavfilter 10. 2.102 / 10. 2.102
libswscale 8. 2.100 / 8. 2.100
libswresample 5. 2.100 / 5. 2.100
libpostproc 58. 2.100 / 58. 2.100
Input #0, mpegts, from 'g:\FANNY AND ALEXANDER [1982(1983)]\FANNY AND ALEXANDER [1982(1983)].m2ts':
Duration: 05:11:37.68, start: 31.712367, bitrate: 20622 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x1011]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn
Stream #0:1[0x1100]: Audio: dts (dca) (DTS-HD MA) ([130][0][0][0] / 0x0082), 48000 Hz, mono, s32p (24 bit)
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> hevc (libx265))
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, ? for help
x265 [info]: HEVC encoder version 3.6+13-06830243f
x265 [info]: build info [Windows][GCC 14.1.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing lslices=6 deblock sao
[mp4 @ 0000000002cb3e80] track 1: codec frame size is not set
Output #0, mp4, to 'e:\Movies4\FANNY AND ALEXANDER [1982(1983)].mp4':
Metadata:
encoder : Lavf61.3.103
Stream #0:0: Video: hevc (hev1 / 0x31766568), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 24k tbn
Metadata:
encoder : Lavc61.5.104 libx265
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
Stream #0:1: Audio: dts (DTS-HD MA) (mp4a / 0x6134706D), 48000 Hz, mono, s32p (24 bit)
[h264 @ 0000000002bb0840] co located POCs unavailable47:51.97 bitrate=16707.3kbits/s dup=47 drop=0 speed=0.0882x
[out#0/mp4 @ 0000000000707400] video:32055261KiB audio:2491223KiB subtitle:0KiB other streams:0KiB global headers:2KiB muxing overhead: 0.058344%
frame=448298 fps=2.3 q=26.0 Lsize=34566640KiB time=05:11:37.67 bitrate=15144.7kbits/s dup=307 drop=1 speed=0.0941x
x265 [info]: frame I: 2424, Avg QP:17.56 kb/s: 35693.16
x265 [info]: frame P: 105171, Avg QP:18.94 kb/s: 24523.76
x265 [info]: frame B: 340703, Avg QP:22.67 kb/s: 10654.36
x265 [info]: Weighted P-Frames: Y:3.1% UV:1.8%
encoded 448298 frames in 198750.88s (2.26 fps), 14043.52 kb/s, Avg QP:21.77
follow-up: 67 comment:66 by , 2 weeks ago
͏ If the sample doesn't bear enough uniqueness...
͏ Need not to batch spam like such:
͏ https://trac.ffmpeg.org/ticket/11052#comment:4
͏ I'm doing final review on the interpreted frame data.
͏ Shall soon post if no error.
comment:67 by , 2 weeks ago
comment:68 by , 2 weeks ago
Replying to Balling:
LOL, your file is horrible, use state of the art software, it has bugs too though
I got DVBinspector installed.
DVBinspector looks questionable.
Zoom in on packets 0..10531. DVBinspector's graph shows packet 3 with PTS 1:33:21.5266. It should also show DTS 1:33:21.4015. It doesn't.
Let's look at the first four frames:
packet 3, an I-frame
PTS: 504137396 -> 1:33:21.5266[2..]
DTS: 504126135 -> 1:33:21.4015
packet 3509, a B-frame
PTS: 504129888 -> 1:33:21.4432
packet 7015, a B-frame
PTS: 504133642 -> 1:33:21.4849[1..]
packet 10531, a P-frame
PTS: 504148657 -> 1:33:21.6517[4..]
DTS: 504137396 -> 1:33:21.5266[2..]
In packets 3..10531 there's 2 DTSes and 4 PTSes -- I'm looking right at the PESes. DVBinspector's graph shows no DTS and 3 PTSes.
I don't really know what you folks are doing, but it looks to me that you've 'tuned' FFmpeg to whatever DVBinspector shows. That DVBinspector is questionable is a problem for FFmpeg, I think.
follow-up: 70 comment:69 by , 2 weeks ago
but it looks to me that you've 'tuned' FFmpeg to whatever DVBinspector shows
Well, dah, how do you think we write code? Report that bug...
comment:70 by , 2 weeks ago
Replying to Balling:
but it looks to me that you've 'tuned' FFmpeg to whatever DVBinspector shows
Well, dah, how do you think we write code?
Hahaha... Yeah. From the outside, in. Find a soft spot, punch in there, build out until it seems to be done and seems to make sense.
There are other ways.
follow-ups: 73 74 75 76 comment:71 by , 2 weeks ago
͏ "Find a soft spot, punch in there, build out until it seems to be done and seems to make sense."
<^> This is how things typically end up broken.
͏ Enough of the examples, need not to enum.
͏ "Tuning FFmpeg to whatever DVBinspector shows"
<^> I don't blindly follow.
by , 2 weeks ago
| Attachment: | Ticket_11055.m2ts.xml added |
|---|
͏ https://streams.videolan.org/ffmpeg/incoming/11055/Ticket_11055.m2ts
͏ (~ 14.77 MiB; M2TS: H.264 (AVC) video, 4.129 s, 23.976 FPS VFR (avg: 12.836, min: 0.499, max: 23.981), 1920x1080, YUV 4:2:0, ~ 13.58 MiB; DTS-HD MA audio, Mono, 4.085 s, 48,000 Hz, 24-Bit, ~ 525.41 KiB; ... ~ 691.57 KiB)
͏ ffprobe -v warning -hide_banner -threads 0 -show_entries "frame" -select_streams v:0 -of "xml" "Ticket_11055.m2ts" -o "Ticket_11055.m2ts.xml"
͏ Note:
[[
<tags> <tag key="timecode" value="01:00:14:22"/> </tags> <side_data_list> <side_data type="SMPTE 12-1 timecode"> <side_datum key="side_data_type" value="SMPTE 12-1 timecode"/> <timecodes> <timecode value="01:00:14:22"/> </timecodes> </side_data> </side_data_list>
]]
͏ Alike repeating for each frame. [1]
͏ Area of interest starts from Line 227. (Frame #18, ts: 5602.235667)
͏ The video has bad timestamps:
͏ |1| Frame #21 (ts: 5602.360789): would last ~ 2 s due to the next frame's PTS. (frames intermediate undetected due OGOP?)
͏ |2| Frame #50 (ts: 5605.405489) onward: timestamps format unexpectedly changed, leading to interpreted PTS overlap.
͏ Points of interest:
͏ |1| For Frame #1 - #49: all have both PTS, DTS present. (#50 - #53 only PTS)
͏ |2| Frame #22 (ts: 5604.362778) has DTS, PTS identical.
͏ |3| The last frame (#27, ts: 5604.571322) of exceptional DTS-PTS time difference is I-frame.
͏ |4| 5604.362778 - 5602.360789 ≈ 1/23.976 * (99 - 53 + 2)
͏ |5| 5605.4889 - 5605.405489 ≈ 1/23.976 * 2
͏ Among the detected frames there was no sign of OGOP (Open GOP).
͏ (all `pict_type="I"` have `key_frame="1"`; nor any H.264 (AVC) recovery point SEI side data present)
͏ See also: https://www.google.com/search?hl=en&gl=ca&num=10&q=%22Open+GOP%22+detect
[ [1]
͏ Brilliant example of bulky engineering and unnecessary sophistry...
͏ https://edlmax.com/SMPTETimeCodeConversion.htm ("Text Formats")
͏ .
͏ That whose existence cannot be justified: let which exist not. ]
follow-up: 84 comment:72 by , 2 weeks ago
͏ Note:
͏ To translate to/from the time base based ts (tbts): interpolate with 1/90000 (tb of this video).
͏ Refactored:
[[
? Packet Analyzer | "-f framecrc" alike | "vf_showinfo" | "-show_frames" variant
____DTS____ ____PTS____| ____DTS____ ____PTS____ | # ____PTS____ T | # ____DTS____ ____PTS____ T
5601.4015 |5601.526622 5601.4015 |5601.526622
|5601.4432 5601.4432 |5601.4432
|5601.484911 5601.484911|5601.484911
5601.526622|5601.651744 5601.526622|5601.651744
|5601.568333 5601.568333|5601.568333
|5601.610033 5601.610033|5601.610033
5601.651744|5601.735167 5601.651744|5601.735167 1|5601.526622|I 1|5601.651744|5601.526622|I
|5601.693456 5601.693456|5601.693456 2|5601.568333|B 2|5601.693456|5601.568333|B
5601.735167|5601.860289 5601.735167|5601.860289 3|5601.610033|B 3|5601.735167|5601.610033|B
|5601.776867 5601.776867|5601.776867 4|5601.651744|P 4|5601.776867|5601.651744|P
|5601.818578 5601.818578|5601.818578 5|5601.693456|B 5|5601.818578|5601.693456|B
5601.860289|5601.9437 5601.860289|5601.9437 6|5601.735167|P 6|5601.860289|5601.735167|P
|5601.902 5601.902 |5601.902 7|5601.776867|B 7|5601.902 |5601.776867|B
5601.9437 |5602.068833 5601.9437 |5602.068833 8|5601.818578|B 8|5601.9437 |5601.818578|B
|5601.985411 5601.985411|5601.985411 9|5601.860289|P 9|5601.985411|5601.860289|P
|5602.027122 5602.027122|5602.027122 10|5601.902 |B 10|5602.027122|5601.902 |B
5602.068833|5602.193956 5602.068833|5602.193956 11|5601.9437 |P 11|5602.068833|5601.9437 |P
|5602.110533 5602.110533|5602.110533 12|5601.985411|B 12|5602.110533|5601.985411|B
|5602.152244 5602.152244|5602.152244 13|5602.027122|B 13|5602.152244|5602.027122|B
5602.193956|5602.277367 5602.193956|5602.277367 14|5602.068833|P 14|5602.193956|5602.068833|P
|5602.235667 5602.235667|5602.235667 15|5602.110533|B 15|5602.235667|5602.110533|B
5602.277367|5602.4025 5602.277367|5602.4025 16|5602.152244|B 16|5602.277367|5602.152244|B
|5602.319078 5602.319078|5602.319078 17|5602.193956|P 17|5602.319078|5602.193956|P
|5602.360789 5602.360789|5602.360789 18|5602.235667|B 18|5602.360789|5602.235667|B
5602.4025 |5602.485911 5602.4025 |5602.485911 19|5602.277367|P 19|5602.4025 |5602.277367|P
|5602.4442 5602.4442 |5602.4442 20|5602.319078|B 20|5602.4442 |5602.319078|B
5602.4859 |5602.527611 5602.4859 |5602.527611
5602.527611|5602.611033 5602.527611|5602.611033
|5602.569322 5602.569322|5602.569322
5602.611033|5602.736156 5602.611033|5602.736156
|5602.652733 5602.652733|5602.652733
|5602.694444 5602.694444|5602.694444
5602.736156|5602.861278 5602.736156|5602.861278
|5602.777867 5602.777867|5602.777867
|5602.819567 5602.819567|5602.819567
5602.861278|5602.9447 5602.861278|5602.9447
|5602.902989 5602.902989|5602.902989
5602.9447 |5603.069822 5602.9447 |5603.069822
|5602.9864 5602.9864 |5602.9864
|5603.028111 5603.028111|5603.028111
5603.069822|5603.194944 5603.069822|5603.194944
|5603.111533 5603.111533|5603.111533
|5603.153233 5603.153233|5603.153233
5603.194944|5603.278367 5603.194944|5603.278367
|5603.236656 5603.236656|5603.236656
5603.278367|5603.403489 5603.278367|5603.403489
|5603.320067 5603.320067|5603.320067
|5603.361778 5603.361778|5603.361778
5603.403489|5603.528611 5603.403489|5603.528611
|5603.4452 5603.4452 |5603.4452
|5603.4869 5603.4869 |5603.4869
5603.528611|5603.612033 5603.528611|5603.612033
|5603.570322 5603.570322|5603.570322
5603.612033|5603.695444 5603.612033|5603.695444
|5603.653733 5603.653733|5603.653733
5603.695444|5603.778867 5603.695444|5603.778867
|5603.737156 5603.737156|5603.737156
5603.778867|5603.862278 5603.778867|5603.862278
|5603.820567 5603.820567|5603.820567
5603.862278|5603.9457 5603.862278|5603.9457
|5603.903989 5603.903989|5603.903989
5603.9457 |5604.029111 5603.9457 |5604.029111
|5603.9874 5603.9874 |5603.9874
5604.029111|5604.112533 5604.029111|5604.112533
|5604.070822 5604.070822|5604.070822
5604.112533|5604.195944 5604.112533|5604.195944
|5604.154233 5604.154233|5604.154233
5604.195944|5604.279367 5604.195944|5604.279367
|5604.237656 5604.237656|5604.237656
5604.279367|5604.404489 5604.279367|5604.404489 21|5602.360789|B 21|5604.279367|5602.360789|B
|5604.321067 5604.321067|5604.321067
|5604.362778 5604.362778|5604.362778 22|5604.362778|B 22|5604.362778|5604.362778|B
5604.404489|5604.529611 5604.404489|5604.529611 23|5604.404489|5602.4025 |P
|5604.4462 5604.4462 |5604.4462 23|5604.404489|P 24|5604.4462 |5604.404489|P
|5604.4879 5604.4879 |5604.4879 25|5604.4879 |5602.4442 |B
5604.529611|5604.654733 5604.529611|5604.654733 24|5604.4462 |P 26|5604.529611|5604.4462 |B
|5604.571322 5604.571322|5604.571322 27|5604.571322|5602.485911|I
|5604.613033 5604.613033|5604.613033 25|5604.4879 |B 28|5604.613033|5604.4879 |B
5604.654733|5604.738156 5604.654733|5604.738156 26|5604.529611|B 29|5604.654733|5604.529611|I
|5604.696444 5604.696444|5604.696444 27|5604.571322|I 30|5604.696444|5604.571322|B
5604.738156|5604.821567 5604.738156|5604.821567 28|5604.613033|B 31|5604.738156|5604.613033|B
|5604.779867 5604.779867|5604.779867 29|5604.654733|I 32|5604.779867|5604.654733|P
5604.821567|5604.9467 5604.821567|5604.9467 30|5604.696444|B 33|5604.821567|5604.696444|B
|5604.863278 5604.863278|5604.863278 31|5604.738156|B 34|5604.863278|5604.738156|P
|5604.904989 5604.904989|5604.904989 32|5604.779867|P 35|5604.904989|5604.779867|B
5604.9467 |5605.071822 5604.9467 |5605.071822 33|5604.821567|B 36|5604.9467 |5604.821567|P
|5604.9884 5604.9884 |5604.9884 34|5604.863278|P 37|5604.9884 |5604.863278|B
|5605.030111 5605.030111|5605.030111 35|5604.904989|B 38|5605.030111|5604.904989|B
5605.071822|5605.196944 5605.071822|5605.196944 36|5604.9467 |P 39|5605.071822|5604.9467 |P
|5605.113533 5605.113533|5605.113533 37|5604.9884 |B 40|5605.113533|5604.9884 |B
|5605.155233 5605.155233|5605.155233 38|5605.030111|B 41|5605.155233|5605.030111|B
5605.196944|5605.280367 5605.196944|5605.280367 39|5605.071822|P 42|5605.196944|5605.071822|P
|5605.238656 5605.238656|5605.238656 40|5605.113533|B 43|5605.238656|5605.113533|B
5605.280367|5605.405489 5605.280367|5605.405489 41|5605.155233|B 44|5605.280367|5605.155233|B
|5605.322067 5605.322067|5605.322067 42|5605.196944|P 45|5605.322067|5605.196944|P
|5605.363778 5605.363778|5605.363778 43|5605.238656|B 46|5605.363778|5605.238656|B
5605.405489|5605.530611 5605.405489|5605.530611 44|5605.280367|B 47|5605.405489|5605.280367|P
|5605.4472 5605.4472 |5605.4472 45|5605.322067|P 48|5605.4472 |5605.322067|B
|5605.4889 5605.4889 |5605.4889 46|5605.363778|B 49|5605.4889 |5605.363778|B
47|5605.405489|P 50| |5605.405489|P
48|5605.4472 |B 51| |5605.4472 |B
49|5605.4889 |B 52| |5605.4889 |B
50|5605.405489|P 53| |5605.530611|I
51|5605.4472 |B
52|5605.4889 |B
53|5605.530611|I
]]
͏ Nominal order as arranged in file. (data offset, ascending)
͏ Frame count:
͏ 99 pre complete decoding
͏ 53 after
͏ ͏"framecrc" alike count before complete decoding: i.e. mere counting the partial frames "Per-packet". [1]
͏ ͏"-vf" etc. complete decode first: then report the interpreted output.
͏ The reported PTS may differ, for the different method determining the actual PTS for display. ("best_effort_timestamp")
[ [1]
͏ No recursion to Hell:
͏ If it has dependency to Hell...
͏ There are also undocumented "uncodedframecrc" alike:
͏ https://github.com/FFmpeg/FFmpeg/commit/dcda5ef1eab52a2392fd8f9ebf51a03052ddfce2
͏ https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/uncodedframecrcenc.c
͏ Some would probably even work without any decoding at all... (unverified) ]
comment:73 by , 2 weeks ago
You should not use FFmpeg to test FFmpeg. If you use FFmpeg or FFprobe, you're just going to get the same bogus, 2 second gap and the same bogus DTSes & PTSes and the same DTS>PTS I got with FFprobe. The packets don't lie.
What about the (correct) numbers out of framecrc? If the 4 second video is crap, why are the framecrc numbers good and why do they agree with the packets, eh?
comment:74 by , 2 weeks ago
comment:75 by , 2 weeks ago
You wrote: "Frame #22 (ts: 5604.362778) has DTS, PTS identical."
That's because it's a B-frame. B-frames _do_not_ have DTSes but FFmpeg pretends that they do. Okay, pretend. If B-frames had DTSes, what DTSes _would_ they have?
comment:76 by , 2 weeks ago
You wrote: "Among the detected frames there was no sign of OGOP (Open GOP)."
Wrong. Every GOP is open GOP.
follow-up: 80 comment:77 by , 2 weeks ago
͏ FF-series tools' output provides a good reference point:
͏ Most players are based on which, regardless; it would be what attained during typical playback.
͏ .
͏ Also the primary purpose is to diagnose FFmpeg: without testing, how could?
͏ As mentioned: the timestamps appeared seriously wrong.
͏ However there appears to be somehow ignored intermediate frames: presumably due to OGOP.
͏ Precisely, all frames may be free of DTS.
͏ However they do exist in some implementations.
͏ .
͏ Regardless, what's parsed by FFprobe indeed contains interpolated data. (that not really exist, but implied by other data)
͏ Don't haste to make early judgment.
͏ Make more analysis on relevant technologies.
͏ ----
͏ [ Quote MasterQuestionable @ CE 2024-06-15 02:59:47 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:48
͏ However which may not be applicable involving B-frames:
͏ Imagining the 1st frame (to present) somehow has dependence on all later frames...
͏ How to decode? ]
<^>͏ Everything dependent must be first decoded.
͏ E.g.
͏ (1), (2), (3): where (1) depends (2), (3):
͏ (2), (3) must be first decoded in regardless order.
follow-up: 83 comment:78 by , 2 weeks ago
@MasterQuestionable and @markfilipak, it is great to see you going through the evidence and comparing specific facts about the test video. However, you seem to be talking past each other.
Each of you is working from different evidence (Ticket_11055.m2ts.xml for @MasterQuestionable and the '-f framecrc' listing in the Description above for @markfilipak). Each of you is making assertions about the test video without showing exactly what data in evidence justifies your assertion. Neither of you seem to be making an effort to correlate your evidence with the other person's.
For instance, @MasterQuestionable says in the attachment description,
The video has bad timestamps:
|1| Frame #21 (ts: 5602.360789): would last ~ 2 s due to the next frame's PTS.…
What is your evidence for this? You link to 264 of the XML attachment. OK, that line in simplified form, and the following <frame> element on line 277, say:
<frame … pts="504212471" pts_time="5602.360789" pkt_dts="504385143" pkt_dts_time="5604.279367" best_effort_timestamp="504212471" best_effort_timestamp_time="5602.360789" … pict_type="B" …> <frame … pts="504392650" pts_time="5604.362778" pkt_dts="504392650" pkt_dts_time="5604.362778" best_effort_timestamp="504392650" best_effort_timestamp_time="5604.362778" … pict_type="B" …>
The pts_time value in Line 277 is 5604.362778, which is about 2 greater than the pts_time value in Line 264 (which is 5602.360789). So what? What does this mean for video playback?
Are you saying that the frame described by Line 277 is physically the next frame in the stream after the frame described by Line 264? What is your evidence for this? Are you saying that the sequence of <frame> elements in the attached XML file matches the sequence of frame data bytes in the video file?
The next <frame> element is line 290, which in simplified form says,
<frame … pts="504216225" pts_time="5602.402500" pkt_dts="504396404" pkt_dts_time="5604.404489" best_effort_timestamp="504396404" best_effort_timestamp_time="5604.404489" … pict_type="P" …>
The pts_time value in Line 290 is 5602.402500, which is less than the pts_time value in Line 277, and about 0.0417 greater than the pts_time value in Line 264. Why should the player not display the Line 290 packet right after the Line 264 packet, and display the Line 277 packet 2 seconds later? If you are going to find common ground with others in the discussion, I think you need to explain these things.
And for instance, @markfilipak says:
You wrote: "Among the detected frames there was no sign of OGOP (Open GOP)."
Wrong. Every GOP is open GOP.
What evidence do you rely on for that? Where in the bug report can others find that evidence? Is it visible in the table you put in the description?
You two might be able to help each other, but I think you won't succeed at doing that until you can find evidence that you both can work with, and until you figure out how to talk to each other instead of past each other.
follow-up: 81 comment:79 by , 2 weeks ago
͏ Done textwall...
͏ See comment:72 for correlation.
͏ "What does this mean for video playback?"
<^> "min: 0.499" FPS
͏ ~ 2 s frame duration during playback.
͏ `ffprobe -show_frames` alike outputs in detected presentation order.
͏ Such inconsistency in timestamps simply means broken.
͏ Note due to the DTS unnecessity: the interpolated polyfill, "best_effort_timestamp" variant is used generally. (as typical real PTS)
͏ See comment:16 for concepts on B-frame.
͏ I didn't expect markfilipak to fix the issue...
͏ Mostly synthesized for self research, also those who could.
comment:80 by , 2 weeks ago
Replying to MasterQuestionable:
͏ FF-series tools' output provides a good reference point:
Only if accurate and reliable, agreed?
͏ Most players are based on which, regardless; it would be what attained during typical playback.
Are you saying that bugs should not be fixed in order to preserve the way that FFmpeg currently works?
͏ Also the primary purpose is to diagnose FFmpeg: without testing, how could?
I have tested. I tested for 2 weeks. On one hand we have show_frames and showinfo, and on the other hand framecrc and a packet analyzer. The one hand disagrees with the other hand. What more testing is needed?
͏ As mentioned: the timestamps appeared seriously wrong.
They do not appear wrong to a packet analyzer. They do not appear wrong to framecrc. They do not play wrong to VLC and PowerDVD. What more do you want?
͏ However there appears to be somehow ignored intermediate frames: presumably due to OGOP.
Please do not presume. Test. If by "intermediate frames" you mean the gap, it is not real. There is no gap in the video. All the GOPs on the Criterion disk have open GOPs, 100%.
͏ Precisely, all frames may be free of DTS.
I don't know what you mean. I- and P-frames must have DTSes.
͏ However they do exist in some implementations.
I don't know what you mean.
͏ Regardless, what's parsed by FFprobe indeed contains interpolated data. (that not really exist, but implied by other data)
What interpolated data? I'm not aware of any interpolation being done. Even if there was interpolation, I don't see what relevance it would have to wrong/backwards/missing DTSes and PTSes.
͏ Don't haste to make early judgment.
I've spent 2 months.
͏ Make more analysis on relevant technologies.
I don't know what you mean. Can you suggest relevant technology that would explain why one part of FFmpeg says one thing and another part of FFmpeg says something very different?
comment:81 by , 2 weeks ago
comment:82 by , 2 weeks ago
͏ Merely the first impression of:
͏ https://trac.ffmpeg.org/ticket/11055?cnum_hist=78&cversion=0#comment:78
͏ Calm and write less shall help:
͏ The board isn't instant messenger...
͏ ----
͏ Accurate or not... it is.
͏ Given its de facto dominance.
͏ Not necessarily.
͏ For this case, something could indeed be done. (for the somehow missing frames due OGOP)
͏ Regardless, there're indeed incorrigible HTTP Referer, Unix $TZ etc. ...
͏ Test the decoding specifically: that directly influences how would such videos generally display.
͏ Other testing tools may not matter as much.
͏ See ͏"Ticket_11055.m2ts.xml".
͏ Mere factual summary, unbiased.
͏ It appears you misunderstood something:
͏ It's not saying everything reported is what the video really of.
͏ It's a factual report of what detected by yet FF-series tools: optimized to better present relevant facts.
͏ "I- and P-frames must have DTS"
<^> Prove the necessity of its existence.
͏ I mean the DTS unnecessity may indeed truly present: as part of the actual file.
͏ "What interpolated data?"
<^> Many.
͏ E.g. comment:79
͏ .
͏ See also: https://github.com/MasterInQuestion/talk/discussions/3#issuecomment-1546820018-4
͏ Poor design, mostly.
͏ But probably wouldn't much matter if just affects testing tools.
͏ Concerning the relevant technologies, I mean everything multi-media related.
͏ Prominently, the relevant video presentation technologies.
͏ ----
͏ "The issue of open GOP is irrelevant"
<^> I doubt so.
͏ Otherwise where went the missing frames?
͏ (if not for such havoc)
͏ I believe those went missing are of OGOP.
comment:83 by , 2 weeks ago
Replying to Jim DeLaHunt:
@MasterQuestionable and @markfilipak, it is great to see you going through the evidence and comparing specific facts about the test video. However, you seem to be talking past each other.
Each of you is working from different evidence (Ticket_11055.m2ts.xml for @MasterQuestionable
Objection, Your Honor. FFprobe is on trial. Claims that it makes cannot be used as evidence.
and the '-f framecrc' listing in the Description above for @markfilipak). Each of you is making assertions about the test video without showing exactly what data in evidence justifies your assertion. Neither of you seem to be making an effort to correlate your evidence with the other person's.
For instance, @MasterQuestionable says in the attachment description,
The video has bad timestamps:
|1| Frame #21 (ts: 5602.360789): would last ~ 2 s due to the next frame's PTS.…
What is your evidence for this? You link to 264 of the XML attachment. OK, that line in simplified form, and the following <frame> element on line 277, say:
Objection, Your Honor. FFprobe is on trial. Claims that it makes cannot be used as evidence.
And for instance, @markfilipak says:
You wrote: "Among the detected frames there was no sign of OGOP (Open GOP)."
Wrong. Every GOP is open GOP.
What evidence do you rely on for that?
Objection, open GOP is not on trial. The issue of open GOP is irrelevant, Your Honor. The question before The Court is the guilt or innocence of showinfo and show_frames plus underlying routines that support them.
comment:84 by , 2 weeks ago
Replying to MasterQuestionable:
͏ Note:
͏ To translate to/from the time base based ts (tbts): interpolate with 1/90000 (tb of this video).
You don't use N*TB/FPS? In this case it's N*90090/24. You interpolate instead? Do I understand you correctly?
comment:85 by , 2 weeks ago
Replying to MasterQuestionable:
͏ “... "-show_frames" shows many of the B-frames having DTS and PTS that don't match.”
Objection, Your Honor. show_frames in on trial. It's claims cannot be used as evidence.
<^> B-frame by definition won't have identical DTS and PTS.
Who's definition? My experience is that B-frames have no DTS. I suppose it's possible, but so what? What relevance does the presence or absence of DTS have on the guilt or innocence of the accused?
follow-ups: 87 110 comment:86 by , 2 weeks ago
͏ I tend to update old posts to avoid pointless cluttering.
͏ Keep in mind.
͏ Trac search all posts CC'd by MasterQuestionable:
͏ https://trac.ffmpeg.org/query?cc=~MasterQuestionable&col=id&col=type&col=summary&col=component&col=keywords&col=reporter&col=status&col=resolution&col=time&col=changetime&order=changetime&desc=1
͏ (descending sorted by last change time)
͏ ----
͏ For your question: comment:79
͏ Note the reported tb (time base) is 1/90000: not 1/90090.
͏ Not I interpolate instead but the decoder/demuxer does.
͏ Regardless time base shouldn't be of concern for modern implementations.
͏ And tbts looks unnatural counter-intuitive.
͏ The output isn't by design generated randomly.
͏ There would be trace: of how and what went wrong.
͏ Refer all contemporary implementations.
͏ Also the theoretical boundary.
comment:87 by , 2 weeks ago
Replying to MasterQuestionable:
͏ I tend to update old posts to avoid pointless cluttering.
͏ Keep in mind.
͏ For your question: comment:79
Regarding comment 79, I did not ask a question in comment 79.
Regarding the content of comment 79:
" ffprobe -show_frames alike outputs in detected presentation order.
͏ Such inconsistency in timestamps simply means broken."
Objection, Your Honor. ffprobe is on trial. It's claims cannot be used as evidence.
͏ The output isn't by design generated randomly.
͏ There would be trace: of how and what went wrong.
Please show me. Show me how ffprobe would know something went wrong. Show me a trace. FFprobe show_frames disagrees with FFmpeg framecrc. Show me how that's possible and that it was traced and then show me how it was handled.
comment:88 by , 2 weeks ago
Ah, I see. Your comment 86 referencing your comment 79 was in response to my comment 85. Sorry, I missed your referencing.
The question was:
"Who's definition? My experience is that B-frames have no DTS. I suppose it's possible, but so what? What relevance does the presence or absence of DTS have on the guilt or innocence of the accused?"
That question still stands: What relevance does the presence or absence of DTS have on the guilt or innocence of showinfo and show_frames? framecrc and a packet analyzer have already testified against the accused. Do the accused have any rebut that doesn't depend on their own testimonies?
follow-up: 90 comment:89 by , 2 weeks ago
| Component: | undetermined → avcodec |
|---|---|
| Keywords: | everything added |
͏ The data selves may make sense.
͏ For those who could make sense: which would be enough "trace".
͏ I don't enjoy lawyering. Your Excellency be at will.
͏ I have a scent that you are trying to pointlessly bump to 100 comments...
͏ Need not to bother. Not really productive.
͏ Your later comments mostly have dependence on comment:78, which I haven't yet finished analyzing:
͏ Thus unable to provide a sensible answer now.
comment:90 by , 2 weeks ago
Replying to MasterQuestionable:
͏ The data selves may make sense.
Whateverthehell that means.
͏ For those who could make sense: which would be enough "trace".
And whateverthehell that means.
͏ I don't enjoy lawyering. Your Excellency be at will.
And whateverthehell that means.
I'm finished with this charade.
comment:91 by , 2 weeks ago
͏ FFprobe doesn't outright give random non-sense: it is not so designed.
͏ The reported data may reveal relevant problems.
͏ I don't enjoy your lawyering tone. Matter of preference, regardless.
follow-up: 93 comment:92 by , 2 weeks ago
͏ After sufficient review, part of your previous comments appear based on false premise.
͏ Please review previous posts.
͏ (prominently near comment:78)
comment:93 by , 2 weeks ago
Replying to MasterQuestionable:
͏ After sufficient review, part of your previous comments appear based on false premise.
͏ Please review previous posts.
͏ (prominently near comment:78)
Who are you addressing? Me or Jim DeLaHunt? Comment 78 was from Jim.
Whether me or Jim, kindly be more specific about comments that appear to be based on false premises. Which comments, and do they apply to the discrepancy between timestamps from FFmpeg functions?
follow-up: 95 comment:94 by , 2 weeks ago
͏ Less verbosity = More readability [ Seemingly true generally. ]
͏ Whom wouldn't much matter.
͏ For you: comment:82
͏ I see your later argument just keeps repeating.
͏ "on trial" "claims" "cannot be used as evidence"
comment:95 by , 2 weeks ago
Replying to MasterQuestionable:
͏ Less verbosity = More readability [ Seemingly true generally. ]
͏ Whom wouldn't much matter.
͏ For you: comment:82
͏ I see your later argument just keeps repeating.
͏ "on trial" "claims" "cannot be used as evidence"
Comment 82 is your comment, not mine. I'm not responsible for what you write.
follow-up: 97 comment:96 by , 2 weeks ago
͏ Judgment without analysis...
͏ No wonder.
͏ Note: comment:82 is B-frame comparable. (logic-wise)
comment:97 by , 2 weeks ago
Replying to MasterQuestionable:
͏ Judgment without analysis...
͏ No wonder.
MasterQuestionable, you write in koans. No one understands koans except the writer.
follow-ups: 99 100 comment:98 by , 2 weeks ago
͏ It appears you failed to parse the context.
͏ Hint: it refers comment:80 and comment:83.
͏ Would you inform what caused the parse failure?
͏ Do you use "Find in Page" alike features?
͏ Do you attempt simple Google Search alike for unrecognized terms?
͏ Though incomplete, from the relevant traces the cause could be determined:
͏ In video presentation terms: DPB overflow.
͏ (Decoding Pictures Buffer Overflow)
͏ ----
͏ Everything already in comment:82: pointless to repeat.
comment:99 by , 2 weeks ago
Please do not hint. Come right out and tell me what you want me to know/do/think.
comment:100 by , 2 weeks ago
͏ Everything already in comment:82: pointless to repeat.
Comment 82 is a string of koans. No one can understand koans. Please write in English sentences that have complete thoughts and explicit subjects and verbs. Thank you.
comment:101 by , 2 weeks ago
͏ Bad English or bad interpreter..?
͏ Presenting comment:80 and comment:82 side-by-side should help you interpreting.
͏ Would you give a screenshot of how you read these comments?
͏ Do you feel the unwieldy segmentation in your comment:80, comment:83?
͏ Somehow related: https://trac.ffmpeg.org/ticket/10989#comment:6
comment:102 by , 2 weeks ago
Ahem, if I may interrupt you...
Why not look at the code instead ? (just sayin')
Have a nice day.
comment:103 by , 2 weeks ago
͏ Why do we need run-time debuggers... instead of comprehending things entirely out of the source?
͏ .
͏ Knowing what went wrong, then could apply relevant fixes:
͏ Rather than doing shotgun debugging...
͏ Good day.
͏ Note: Linguistics is also of my researches.
comment:104 by , 2 weeks ago
MasterQuestionable, you know that what you're doing here is a form of harassment that can be considered psychological torture, don't you? Amnesty International did an entire movie about this sort of treatment, Closet Land.
Now I suggest you stop playing and allow this bug submission to proceed.
comment:105 by , 2 weeks ago
͏ "Reason cannot be discerned without discerning."
͏ https://trac.ffmpeg.org/ticket/11002#comment:13
͏ We shall be focusing on the facts, not personal tastes.
͏ "Angry may again be happy. Enraged may again be glad."
comment:106 by , 2 weeks ago
| Keywords: | vf_showinfo ffprobe -show_frames removed |
|---|---|
| Status: | new → open |
| Summary: | "showinfo", "-show_frames": bad PTS, where "framecrc" had expected; plus inconsistent playback → OGOP (Open GOP) in certain conditions may cause missing frames of decoding |
comment:107 by , 13 days ago
| Resolution: | → invalid |
|---|---|
| Status: | open → closed |
Kindly take your flame war elsewhere, this bug tracker is not the place for it. Closing the bug as invalid, nobody's reading all the above garbage.
If you want it actually fixed, open a new one with more sanity.
comment:108 by , 13 days ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
͏ Made better sense out from the table.
͏ Posted in comment:72.
͏ The problem exists.
͏ Regardless far more readable than the project's source...
͏ Ideally some of the posts should be rearranged to different threads.
͏ However due to the management obstacle...
͏ ----
͏ Concerning the issue's complexity... I fear opening new ones won't help.
͏ (mostly could only be worse)
͏ Less = More truly...
follow-up: 112 comment:109 by , 13 days ago
͏ "I made a 4 second clip having 99 actual frames."
͏ ("Ticket_11055.m2ts")
͏ .
͏ How is it generated?
͏ "VLC and PowerDVD play the clip perfectly."
<^>͏ As VLC internally uses what based FFmpeg:
͏ Would this indicate which being a regression..?
͏ What VLC version?
comment:110 by , 13 days ago
Replying to MasterQuestionable:
͏ For your question: comment:79
͏ Note the reported tb (time base) is 1/90000: not 1/90090.
I'm sorry. 90090 is 90000*1.001. I often skip from
N/(1/90000)/(24/1.001)
directly to
N/90090/24
when doing my calculations. Sorry if that confused you. You see, I think of
90090/24
as ticks per frame (TPF). So the calculation becomes, simply,
N*TPF
In the case of 24/1.001 FPS, TPF = 90090/24 = 3753.75 tpf.
follow-up: 113 comment:111 by , 13 days ago
͏ Wouldn't much matter.
͏ However you'd better confirm your table didn't have any data error:
͏ Which my refactoring is directly based on (without validation).
comment:112 by , 13 days ago
Replying to MasterQuestionable:
͏ "I made a 4 second clip having 99 actual frames."
͏ ("Ticket_11055.m2ts")
͏ .
͏ How is it generated?
I can give you all the Windows scripts. There are 4.
I started with 00305.m2ts and 00306.m2ts.
I cut off the front and back from each of them making sure all four cut ends are IDR.
(I used '-bsf noise' to do the cutting and '-bsf setts' to make the IDR ends.)
I concatenated the two episodes.
(Spliced together, they had 2:47:53 running time.)
I cut out the 4 second section at the join (i.e., the join time +/- 2 seconds).
(I wasn't meticulous cutting that 4 second section. I used '-ss' and '-to'. As a result, the ends are not IDR.)
I renamed the 4 second section to "Ticket_11055.m2ts" and uploaded it to trac.
comment:113 by , 13 days ago
Replying to MasterQuestionable:
͏ Wouldn't much matter.
͏ However you'd better confirm your table didn't have any data error:
͏ Which my refactoring is directly based on (without validation).
It doesn't matter at all. It's the same calculation. Look:
N/(1/90000)/(24/1.001) = N*90000*1.001/24 = N*90090/24 = N*TPF
where TPF = 90090/24.
For cine-slow, TPF = 90090/24 = 3753.75 ticks-per-frame.
For pseudo PAL, TPF = 90000/25 = 3600 ticks-per-frame.
For pseudo NTSC, TPF = 90090/30 = 3003 ticks-per-frame.
follow-up: 115 comment:114 by , 13 days ago
͏ There's significant likelihood that "Ticket_11055.m2ts" is factually broken.
͏ (also somewhat testifiable in the frame analysis)
͏ Regardless, your description would provide some hints for the potential optimization.
comment:115 by , 13 days ago
Replying to MasterQuestionable:
͏ There's significant likelihood that "Ticket_11055.m2ts" is factually broken.
If you discover it, please tell me. I'm eager to know.
͏ (also somewhat testifiable in the frame analysis)
͏ Regardless, your description would provide some hints for the potential optimization.
Would you like the Windows scripts I used to do all the cutting? I'd value your opinion.
follow-up: 117 comment:116 by , 13 days ago
͏ Currently, no. (your description appeared sufficient)
͏ (regardless no input file so no real use...)
͏ Actually already mentioned before:
͏ Timestamps in "Ticket_11055.m2ts.xml".
͏ ("01:00:14:22" and "02:32:44:04" alike..?)
͏ .
͏ Appears bad splicing.
͏ Also per the tricky nature of OGOP. (see comment:17)
͏ Cutting joining without re-encoding such mostly would be bug-ridden.
comment:117 by , 13 days ago
Replying to MasterQuestionable:
͏ Actually already mentioned before:
͏ Timestamps in "Ticket_11055.m2ts.xml".
͏ ("01:00:14:22" and "02:32:44:04" alike..?)
Yes, SMPTE 12-1 time codes. I see no way to change them during the splice.
͏ [It] Appears [to be] bad splicing.
I agree. Is that because of the SMPTE time codes? It's "side data". I've never understood what "side data" is. I've asked several times on ffmpeg-user but no one answered. The docs mention "side data" but don't explain what it is, how it's used, that it can be changed, or how it can be changed; just that there is a thing called "side data".
comment:118 by , 13 days ago
While I have your eye, MasterQuestionable, may I ask a question?
What I did was rip all four episodes, then trim them, then concatenate them, then transcode them to HEVC-MP4. I did it in that order because I thought I'd get the best results ... all streams with a single timebase, you know.
The end result: HEVC-MP4 did not play well at the joins and crashed PowerDVD on loading.
I'm now redoing everything in this order: rip-convert to HEVC-MP4, then trim, then concatenate. The HEVC-MP4s will have differing stream timebases that may complicate the trimming. I'm crossing my fingers. What do you think?
follow-up: 121 comment:119 by , 13 days ago
͏ Sort of metadata. Doesn't make much sense.
͏ [ Notorious examples being the metadata in image files. (EXIF etc.) ]
͏ Unsure, but FFmpeg tends to ignore useless things.
͏ On your question:
͏ https://github.com/MasterInQuestion/talk/discussions/32#discussioncomment-9798911
comment:120 by , 13 days ago
I redid the Summary of the bug table. I arranged show_frames in DTS order. It's better, more informative. And somehow I missed N=17 in the original table.
__packet analyzer__ _____framecrc______ ___showinfo___ ______show_frames_______
(physical order) (DTS order) (DTS order) (DTS order)
___DTS___ ___PTS___ ___DTS___ ___PTS___ N ___PTS___ N ___DTS___ ___PTS___
504126135 504137396 504126135 504137396 0 504137396 I
504129888 504129888 504129888
504133642 504133642 504133642
504137396 504148657 504137396 504148657 3 504148657 P
504141150 504141150 504141150 1 504141150 B
504144903 504144903 504144903 2 504144903 B
504148657 504156165 504148657 504156165 5 504156165 P 0 504148657 504137396 I
504152411 504152411 504152411 4 504152411 B 1 504152411 504141150 B
504156165 504167426 504156165 504167426 8 504167426 P 2 504156165 504144903 B
504159918 504159918 504159918 6 504159918 B 3 504159918 504148657 P
504163672 504163672 504163672 7 504163672 B 4 504163672 504152411 B
504167426 504174933 504167426 504174933 10 504174933 P 5 504167426 504156165 P
504171180 504171180 504171180 9 504171180 B 6 504171180 504159918 B
504174933 504186195 504174933 504186195 13 504186195 P 7 504174933 504163672 B
504178687 504178687 504178687 11 504178687 B 8 504178687 504167426 P
504182441 504182441 504182441 12 504182441 B 9 504182441 504171180 B
504186195 504197456 504186195 504197456 16 504197456 P 10 504186195 504174933 P
504189948 504189948 504189948 14 504189948 B 11 504189948 504178687 B
504193702 504193702 504193702 15 504193702 B 12 504193702 504182441 B
504197456 504204963 504197456 504204963 18 504204963 P 13 504197456 504186195 P
504201210 504201210 504201210 17 504201210 B 14 504201210 504189948 B
504204963 504216225 504204963 504216225 15 504204963 504193702 B
504208717 504208717 504208717 19 504208717 B 16 504208717 504197456 P
504212471 504212471 504212471 20 504212471 B 17 504212471 504201210 B
504216225 504223732 504216225 504223732 18 504216225 504204963 P
504219978 504219978 504219978 19 504219978 504208717 B
===================== SPLICE HERE ====================== ¦
504223731 504227485 504223731 504227485 these DTSes = PTSes + 3 frames
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 these DTSes = PTSes + 3 frames
504381389 504381389 504381389 ¦
504385143 504396404 504385143 504396404 22 504396404 P 20 504385143 504212471 B
504388896 504388896 504388896
504392650 504392650 504392650 21 504392650 B 21 504392650 504392650 B
504396404 504407665 504396404 504407665 25 504407665 B 22 504396404 504216225 P
504400158 504400158 504400158 23 504400158 P 23 504400158 504396404 P
504403911 504403911 504403911 24 504403911 B 24 504403911 504219978 B
504407665 504418926 504407665 504418926 28 504418926 I 25 504407665 504400158 B
504411419 504411419 504411419 26 504411419 I 26 504411419 504223732 I
504415173 504415173 504415173 27 504415173 B 27 504415173 504403911 B
504418926 504426434 504418926 504426434 30 504426434 B 28 504418926 504407665 I
504422680 504422680 504422680 29 504422680 B 29 504422680 504411419 B
504426434 504433941 504426434 504433941 32 504433941 B 30 504426434 504415173 B
504430188 504430188 504430188 31 504430188 P 31 504430188 504418926 P
504433941 504445203 504433941 504445203 35 504445203 P 32 504433941 504422680 B
504437695 504437695 504437695 33 504437695 P 33 504437695 504426434 P
504441449 504441449 504441449 34 504441449 B 34 504441449 504430188 B
504445203 504456464 504445203 504456464 38 504456464 P 35 504445203 504433941 P
504448956 504448956 504448956 36 504448956 B 36 504448956 504437695 B
504452710 504452710 504452710 37 504452710 B 37 504452710 504441449 B
504456464 504467725 504456464 504467725 41 504467725 P 38 504456464 504445203 P
504460218 504460218 504460218 39 504460218 B 39 504460218 504448956 B
504463971 504463971 504463971 40 504463971 B 40 504463971 504452710 B
504467725 504475233 504467725 504475233 43 504475233 B 41 504467725 504456464 P
504471479 504471479 504471479 42 504471479 B 42 504471479 504460218 B
504475233 504486494 504475233 504486494 46 504486494 P 43 504475233 504463971 B
504478986 504478986 504478986 44 504478986 P 44 504478986 504467725 P
504482740 504482740 504482740 45 504482740 B 45 504482740 504471479 B
504486494 504497755 504486494 504497755 52 504497755 I 46 504486494 504475233 P
504490248 504490248 504490248 47 504490248 B 47 504490248 504478986 B
504494001 504494001 504494001 48 504494001 B 48 504494001 504482740 B
repeat -> 49 504486494 P
repeat -> 50 504490248 B
repeat -> 51 504494001 B
49 "N/A" 504486494 P
50 "N/A" 504490248 B
51 "N/A" 504494001 B
52 "N/A" 504497755 I
Edit: The "_showinfo_" column was marked "(PTS order)". That was wrong. I put the column in DTS order. Though DTS is not returned by showinfo, I was able to put showinfo in DTS order by correlating PTSes with the framecrc column (which is in DTS order).
comment:121 by , 13 days ago
Replying to MasterQuestionable:
͏ On your question:
͏ https://github.com/MasterInQuestion/talk/discussions/32#discussioncomment-9798911
I don't understand any aspect of https://github.com/MasterInQuestion/talk/discussions/32. Where did it come from? Why does it discuss lossless?
In it is this:
"You seem to lack adequate understanding on the video presentation things: Notably the concept of B-frame."
You're joking, right? None of this stuff seems intended for me.
comment:122 by , 13 days ago
Oh, I just remembered...
About a month ago 'pkt_dts' showed up in 'show_frames'. It was not there before. I think that's when 'show_frames' broke.
Actually, now that I think about it, it may have been broken before 'pkt_dts' but I just didn't know it.
comment:123 by , 13 days ago
Ah, I think I see one problem:
When I roughly cut the 4 second segment, I cut on an I-frame but I used '-ss' to do the cutting -- it was not a IDR cut. Apparently it cut off the first P-frame -- the one that would/should have come between the first I-frame and the 1st B-frame.
I'll redo it, this time with IDR cuts, and upload it as 'Ticket_11055-1.m2ts'. Please stand by.
comment:124 by , 12 days ago
Yes! '-ss' left a mess.
These two B-frames --------------------+
¦
__packet analyzer__ _____framecrc______ ¦
(physical order) (DTS order) ¦
___DTS___ ___PTS___ ___DTS___ ___PTS___ ¦
504126135 504137396 504126135 504137396 ¦
504129888 504129888 504129888 <--+
504133642 504133642 504133642 <--+
504137396 504148657 504137396 504148657
need to be removed and the I-frame at DTS 504126135 needs to be moved to 504133642.
That's easy. As soon as my current job is finished, I'll do that and examine the result and maybe exonerate showinfo and show_frames. Stay tuned to this channel.
follow-ups: 126 127 128 132 comment:125 by , 12 days ago
͏ You may edit the summary directly.
͏ Double-posting is bad.
͏ Also refer comment:72.
͏ (I shall diff your edit later to tell the change; your description shall also help)
͏ Post less-on-topic on relevant threads.
͏ Thanks.
͏ "pkt_dts" alike exist since old.
͏ Keyword "DTS unnecessity" in this thread.
͏ I'll verify how seeking things work.
͏ (seemingly indeed somehow misbehaving: on the timestamp translation to actual frame number)
͏ See: https://trac.ffmpeg.org/ticket/11060
͏ Relevant findings shall be posted there.
comment:126 by , 12 days ago
Replying to MasterQuestionable:
͏ You may edit the summary directly.
Thanks, but I couldn't find a way to do that.
comment:127 by , 12 days ago
Replying to MasterQuestionable:
͏ Also refer comment:72.
͏ (I shall diff your edit later to tell the change; your description shall also help)
My comment 120 is better than your comment 72 in my opinion because it more accurately shows what happens at the end of the stream.
comment:128 by , 12 days ago
Replying to MasterQuestionable:
͏ Post less-on-topic on relevant threads.
͏ Thanks.
I'm sorry, I don't know to what you refer.
Y'know, posting multiple comments about differing subjects makes this process harder.
comment:129 by , 12 days ago
These are most important questions.
In 'show_frames', I see a point where 'best_effort_timestamp' switches from 'pts' to 'pkt_dts'. I had not been paying attention to that. I am now. Why does 'best_effort_timestamp' exist? What conditions (or situations) trigger the use of 'best_effort_timestamp' that is not 'pts'?
Should I add 'best_effort_timestamp' to comment 120?
This block is where 'best_effort_timestamp' switches to 'pkt_dts'.
504392650 504392650 504392650 21 504392650 B 21 504392650 504392650 B
504396404 504407665 504396404 504407665 25 504407665 B 22 504396404 504216225 P
504400158 504400158 504400158 23 504400158 P 23 504400158 504396404 P
504403911 504403911 504403911 24 504403911 B 24 504403911 504219978 B
504407665 504418926 504407665 504418926 28 504418926 I 25 504407665 504400158 B
504411419 504411419 504411419 26 504411419 I 26 504411419 504223732 I
504415173 504415173 504415173 27 504415173 B 27 504415173 504403911 B
504418926 504426434 504418926 504426434 30 504426434 B 28 504418926 504407665 I
504422680 504422680 504422680 29 504422680 B 29 504422680 504411419 B
504426434 504433941 504426434 504433941 32 504433941 B 30 504426434 504415173 B
504430188 504430188 504430188 31 504430188 P 31 504430188 504418926 P
504433941 504445203 504433941 504445203 35 504445203 P 32 504433941 504422680 B
504437695 504437695 504437695 33 504437695 P 33 504437695 504426434 P
504441449 504441449 504441449 34 504441449 B 34 504441449 504430188 B
504445203 504456464 504445203 504456464 38 504456464 P 35 504445203 504433941 P
504448956 504448956 504448956 36 504448956 B 36 504448956 504437695 B
504452710 504452710 504452710 37 504452710 B 37 504452710 504441449 B
504456464 504467725 504456464 504467725 41 504467725 P 38 504456464 504445203 P
504460218 504460218 504460218 39 504460218 B 39 504460218 504448956 B
504463971 504463971 504463971 40 504463971 B 40 504463971 504452710 B
504467725 504475233 504467725 504475233 43 504475233 B 41 504467725 504456464 P
504471479 504471479 504471479 42 504471479 B 42 504471479 504460218 B
504475233 504486494 504475233 504486494 46 504486494 P 43 504475233 504463971 B
504478986 504478986 504478986 44 504478986 P 44 504478986 504467725 P
504482740 504482740 504482740 45 504482740 B 45 504482740 504471479 B
504486494 504497755 504486494 504497755 52 504497755 I 46 504486494 504475233 P
504490248 504490248 504490248 47 504490248 B 47 504490248 504478986 B
504494001 504494001 504494001 48 504494001 B 48 504494001 504482740 B
follow-up: 131 comment:130 by , 12 days ago
͏ For your non-directly on-topic questions, post on:
͏ https://github.com/MasterInQuestion/talk/discussions/32
͏ Mentioned before in this thread.
͏ "best_effort_timestamp" is same as PTS reported by "vf_showinfo".
comment:132 by , 12 days ago
Replying to MasterQuestionable:
͏ I'll verify how seeking things work.
͏ (seemingly indeed somehow misbehaving: on the timestamp translation to actual frame number)
What are 'seeking things'? Are they functions? What do they seek? Where do they seek?
comment:133 by , 12 days ago
͏ It appears you do not remember what you say...
͏ Search before ask, I'd suggest.
͏ https://trac.ffmpeg.org/wiki/Seeking
comment:134 by , 12 days ago
| Description: | modified (diff) |
|---|
comment:135 by , 12 days ago
| Description: | modified (diff) |
|---|
comment:136 by , 12 days ago
| Description: | modified (diff) |
|---|
comment:137 by , 12 days ago
I completed the task: make the beginning of Ticket_11055.m2ts an IDR . Aside from the two B-frames that were removed, there's no change to the framecrc, showinfo, and show_frames outputs.
follow-up: 140 comment:138 by , 12 days ago
| Priority: | important → normal |
|---|
͏ Normalize priority.
͏ I think this only influences not very much cases, mostly coined:
͏ That only involves illy-produced videos.
͏ Doesn't merit high priority as one that could wreak general havoc.
comment:139 by , 11 days ago
I asked to fix wireshark parser: https://gitlab.com/wireshark/wireshark/-/merge_requests/16027
and now we have better checker, but it does not show TP_extra_header yet, but after fix it at least shows all packets correctly (188 bytes of 192 packet for now). Install latest wireshark here: https://www.wireshark.org/download/automated/win64/Wireshark-4.3.0rc1-84-g9e5cbbaceeea-x64.exe
comment:140 by , 11 days ago
Replying to MasterQuestionable:
͏ Normalize priority.
͏ I think this only influences not very much cases, mostly coined:
͏ That only involves illy-produced videos.
͏ Doesn't merit high priority as one that could wreak general havoc.
Please find something wrong with https://streams.videolan.org/ffmpeg/incoming/11055/Ticket_11055.m2ts. I'd dearly like to know what it is. If it is "illy-produced", show how it is "illy-produced". When "I think" becomes "We show", then I will believe it.
I think this may be a far ranging bug that affects '-ss' and that provokes many of the "non-monotonous DTS" error messages that seem to appear out of nowhere when a trivial, non-timing, non-timestamp change is made to a transcode or to a remux. I confess that I write "I think" rather than "We think" because I've not yet gotten others on ffmpeg-user to look at Ticket_11055.m2ts and to take this issue seriously enough to join me. Certainly, no one else on ffmpeg-user has communicated that they've tested (or even watched) Ticket_11055.m2ts.
This bug clearly wrecks '-vf showinfo' and '-show_frames' and makes them useless.
According to an examination of the actual packets, only '-f framecrc' reports correctly.
Please do not downgrade this bug without actual proof that it is "illy-produced".
Edit: Two minor wording corrections.
follow-ups: 149 150 comment:141 by , 10 days ago
͏ Not specifically on your file: on OGOP (Open GOP) in general.
͏ (rationale explained well before; comment:17 notably)
͏ "non-monotonous DTS" messages are warning, I believe: mere indicating the peculiarity of the input timestamps.
͏ comment:72 explained why and how. ("framecrc" "-vf" etc.)
͏ Meanwhile, I wonder:
͏ Could the origin inputs ("00305.m2ts", "00306.m2ts") be decoded without similar problem?
͏ .
͏ Verifiable with alike:
͏ ffmpeg -v debug -hide_banner -nostdin -nostats -i "00305.m2ts" -map v:0 -c rawvideo -f null -
͏ (shall report the packet count for comparison)
follow-ups: 143 144 comment:142 by , 9 days ago
I believe you can't just concatenate files like this since that will invalidate PCR and arrival timestamps in TP_extra_header.
https://github.com/justdan96/tsMuxer/issues/108
https://forum.doom9.org/showthread.php?p=1105850#post1105850
https://forum.doom9.org/showthread.php?p=1576718#post1576718
comment:143 by , 9 days ago
Replying to Balling:
I believe you can't just concatenate files like this since that will invalidate PCR and arrival timestamps in TP_extra_header.
https://github.com/justdan96/tsMuxer/issues/108
https://forum.doom9.org/showthread.php?p=1105850#post1105850
https://forum.doom9.org/showthread.php?p=1576718#post1576718
Thank you Balling. I have begun to read the articles. That will take some time because they contain more links to other posts. I appreciate your contribution. May I ask you two questions?
Question 1:
Why do the timestamps in this:
ffmpeg -copyts -i Ticket_11055.m2ts -map 0:v -vf showinfo -c:v rawvideo -f null -muxdelay 0 - 2>Ticket_11055.m2ts_showinfo.txt
differ from the timestamps in this:
ffmpeg -i Ticket_11055.m2ts -map 0 -copyts -c copy -dn -sn -f framecrc - >Ticket_11055.m2ts_framecrc.txt
Note that the timestamps in framecrc match the actual packets in Ticket_11055.m2ts.
Question 2:
Why do the timestamps in this:
ffprobe -sexagesimal -select_streams v -show_frames -of flat -i Ticket_11055.m2ts >Ticket_11055.m2ts_show_frames.txt
differ from the timestamps in this:
ffmpeg -i Ticket_11055.m2ts -map 0 -copyts -c copy -dn -sn -f framecrc - >Ticket_11055.m2ts_framecrc.txt
Note that the timestamps in framecrc match the actual packets in Ticket_11055.m2ts.
Thank you.
comment:144 by , 9 days ago
You mentioned "TP_extra_header".
From here:
"M2TS is the video stream packet format used on Blu-ray discs. M2TS is similar to fmt/585 - MPEG-2 Transport Stream, but instead features 192 byte packets, with a 4 byte TP_extra_header preceeding [sic] each 188 byte transport packet. Filenames usually take the form 'xxxxx.mts' or xxxxx.m2ts' where xxxxx represents a numeric value, beginning with 00000 and incrementing by 1 for each stream."
I confirm with a hex editor that my sources: 00305.m2ts, 00306.m2ts, 00307.m2ts, and 00308.m2ts have 192 byte TSs. Is that relevant?
Correction: "192 byte TSs" was "192 byte TPs".
comment:145 by , 9 days ago
| Description: | modified (diff) |
|---|
follow-up: 148 comment:146 by , 8 days ago
Is that relevant?
Yes, that is what I am talking about... Of course.
BTW, https://ffmpeg.org/pipermail/ffmpeg-user/2024-June/058057.html
MPV player shows "bt.709".
It is wrong, if it is unknown it is unknown. FFmpeg assumes BT.601 in all cases, not checking the height.
comment:147 by , 8 days ago
͏ "non-monotonous DTS" messages are warning, I believe
No. The DTS timestamps MUST be strictly monotonic.
comment:148 by , 8 days ago
I meant "Is that relevant" to the issue at hand in this ticket: wrong time stamps from the following?
ffmpeg -copyts -i Ticket_11055.m2ts -map 0:v -vf showinfo -c:v rawvideo -f null -muxdelay 0 - 2>Ticket_11055.m2ts_showinfo.txt
and
ffprobe -sexagesimal -select_streams v -show_frames -of flat -i Ticket_11055.m2ts >Ticket_11055.m2ts_show_frames.txt
by , 8 days ago
| Attachment: | 00305.m2ts nostats.zip added |
|---|
The output of 'ffmpeg -v debug -hide_banner -nostdin -nostats -i c:\00305.m2ts -map v:0 -c copy -f null - 2>"c:\00305.m2ts nostats.txt"'
comment:149 by , 8 days ago
Replying to MasterQuestionable:
͏ Not specifically on your file: on OGOP (Open GOP) in general.
͏ (rationale explained well before; comment:17 notably)
͏ "non-monotonous DTS" messages are warning, I believe: mere indicating the peculiarity of the input timestamps.
͏ comment:72 explained why and how. ("framecrc" "-vf" etc.)
͏ Meanwhile, I wonder:
͏ Could the origin inputs ("00305.m2ts", "00306.m2ts") be decoded without similar problem?
͏ .
͏ Verifiable with alike:
͏ffmpeg -v debug -hide_banner -nostdin -nostats -i "00305.m2ts" -map v:0 -c copy -f null -
͏ (shall report the packet count for comparison)
Did you want me to run that command?
I ran this:
ffmpeg -v debug -hide_banner -nostdin -nostats -i c:\00305.m2ts -map v:0 -c copy -f null - 2>"c:\00305.m2ts nostats.txt"
'00305.m2ts nostats.zip' is attached.
A debug log file was not created (?).
comment:150 by , 8 days ago
Replying to MasterQuestionable:
͏ Not specifically on your file: on OGOP (Open GOP) in general.
͏ (rationale explained well before; comment:17 notably)
͏ "non-monotonous DTS" messages are warning, I believe: mere indicating the peculiarity of the input timestamps.
To make it clearly understood, I did not get any "non-monotonous DTS" messages in this case.
follow-up: 154 comment:151 by , 7 days ago
͏ Reading the mail list is painful...
͏ Horrible layout.
͏ And tricky via 3rd-party API:
͏ https://www.mail-archive.com/search?l=ffmpeg-user@ffmpeg.org&q=subject:%22I+found+the+bugs%22&o=oldest&f=1
͏ https://www.mail-archive.com/search?l=ffmpeg-user@ffmpeg.org&q=from:%22Mark+Filipak%22&o=newest
͏ If every post is viewed in alike poorly sliced segments... No wonder the parse failure.
͏ ----
͏ Note it's "Non-monotonic":
͏ https://github.com/search?type=code&q=repo:FFmpeg/FFmpeg+/(?:%5B%5CW_%5D|^)Non%5B%5C-%20%5Dmonoton(?:ic|ous)/
͏ See also:
͏ https://github.com/FFmpeg/FFmpeg/blob/ed9363052f4b8b89ed2f1415f392d39788dab0d3/libavformat/avformat.h#L481
͏ ----
͏ "packets muxed", "packets read" may indicate.
͏ Compare the packet count of "-f framecrc" alike (or ? Packet Analyzer).
͏ Change "-c copy" to "-c rawvideo":
͏ For "-c copy" on "Ticket_11055.m2ts" reports "99 packets muxed".
comment:152 by , 7 days ago
͏ [ Quote MasterQuestionable @ CE 2024-06-18 13:32:27 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:72
͏ ͏"framecrc" alike count before complete decoding: i.e. mere counting the partial frames "Per-packet". [1]
͏ ͏"-vf" etc. complete decode first: then report the interpreted output.
͏ The reported PTS may differ, for the different method determining the actual PTS for display. ("best_effort_timestamp") ]
comment:154 by , 7 days ago
Replying to MasterQuestionable:
͏ Note it's "Non-monotonic":
What is it that is non-monotonic?
What is that?
͏ See also:
͏ https://github.com/FFmpeg/FFmpeg/blob/ed9363052f4b8b89ed2f1415f392d39788dab0d3/libavformat/avformat.h#L481
Why are you showing me source code?
͏ "packets muxed", "packets read" may indicate.
͏ Compare the packet count of "-f framecrc" alike (or ? Packet Analyzer).
͏ Change "-c copy" to "-c rawvideo":
͏ For "-c copy" on "Ticket_11055.m2ts" reports "99 packets muxed".
Yes. There are 99 TS packets that contain PID 4113 (i.e., 0x1011) PS packs that contain PES headers.
I created a table of all that information in the "Summary of the bug". It took me two weeks to figure out what happened. I put it all in a table so you folks would see it with minimal time and effort. I hope I didn't waste those two weeks.
MasterQuestionable, you are not utilizing the "Reply" link, so I don't know what you're replying to. Are you replying to a previous message?
Edit: Made "non-monotonic" statement clearer given the controversy over the word "monotonic" versus "monotonous".
Edit: Changed "PS packs" to "PS packs that contain PES headers". I'm trying to be exact.
comment:155 by , 7 days ago
Comment: I don't understand why MasterQuestionable is trying to debug Ticket_11055.m2ts. That is not the issue.
The issue is that timestamps reported by 'showinfo' and 'show_frames' disagree with reality and with each other. The issue is that I suspect that whatever code is supplying bogus timestamps to them is also supplying bogus timestamps to '-to' and is also responsible for many of the 'non-monotonic DTS' notices that appear sometimes (but not this time).
follow-up: 158 comment:156 by , 7 days ago
͏ Read context. (± 15 surrounding posts expected)
͏ [ Through search preferable; but mostly shouldn't be necessary. ]
͏ Reincluding what's just a few lines away creates excessive verbosity:
͏ Which may in turn downgrade readability.
͏ And all which of "Ticket_11055.m2ts"..?
͏ What is unclear in comment:72?
͏ I believe everything's been already mentioned.
͏ The interpreted B-frames' DTS seems seriously wrong.
͏ (non-sense per B-frame's nature)
͏ I wonder if the issue would influence "00305.m2ts", "00306.m2ts".
͏ (so avoiding the possibility of "Ticket_11055.m2ts" improperly produced)
follow-up: 159 comment:157 by , 7 days ago
͏ "Application provided invalid, non monotonically increasing dts to muxer in stream 0"
͏ This should be an important message of the output.
͏ Whatsoever not initially mentioned.
comment:158 by , 7 days ago
Replying to MasterQuestionable:
͏ Read context. (± 15 surrounding posts expected)
͏ [ Through search preferable; but mostly shouldn't be necessary. ]
I have no idea what you are referring to.
͏ Reincluding what's just a few lines away creates excessive verbosity:
͏ Which may in turn downgrade readability.
Please use the "Reply" link when replying. I use "(o) Threaded" mode in these strings of replies and when you don't use "Reply" then I, and the threading mechanism, don't know what to do and can't find what you are replying to.
͏ And all which of "Ticket_11055.m2ts"..?
I have no idea what you are 'saying'.
͏ What is unclear in comment:72?
͏ I believe everything's been already mentioned.
In your comment 72, you multiplied the DTSes and PTSes by 3753.75 ticks-per-frame. Why did you do that?
͏ The interpreted B-frames' DTS seems seriously wrong.
͏ (non-sense per B-frame's nature)
All the DTSes and PTSes in the left hand column of the table in "Summary of the bug" are directly from the PES packets.
͏ I wonder if the issue would influence "00305.m2ts", "00306.m2ts".
͏ (so avoiding the possibility of "Ticket_11055.m2ts" improperly produced)
What would you like me to do? Do you want me to print all the PTSes and DTSes in 00305.m2ts and 00306.m2ts? I will do whatever you want. I think this bug is critical, and this case provides a perfect way to fix it simply by tracing the code that works from framecrc into and through the library functions versus the code that doesn't work from showinfo and show_frames into and through the library functions.
Look at my table -- the table in the "Summary of the bug". Look at the columns for
__packet analyzer__
and
_____framecrc______
. Do you not believe those DTSes and PTSes?
I understand that 'showinfo' presents timestamps _after_ decoding. Why are those timestamps different?
I'm not sure that 'show_frames' presents timestamps _after_ decoding or not.
So much of FFmpeg is mysterious because it's not documented. Why/how are 'showinfo' and 'show-frames' getting bad DTSes and PTSes?
I will do anything to help. What can I do?
Edit: "ticks-per-frame" was "ticks-per-second" -- oops.
comment:159 by , 7 days ago
Replying to MasterQuestionable:
͏ "Application provided invalid, non monotonically increasing dts to muxer in stream 0"
͏ This should be an important message of the output.
͏ Whatsoever not initially mentioned.
Why did you write that?
follow-ups: 161 162 comment:160 by , 6 days ago
͏ Threaded mode? What is that?
͏ Accessing [ https://trac.ffmpeg.org/ticket/11055 ] without passing cookies is my typical view.
͏ [ Quote MasterQuestionable @ CE 2024-06-16 08:34:09 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:86
͏ Regardless time base shouldn't be of concern for modern implementations.
͏ And tbts looks unnatural counter-intuitive. ]
͏ ffmpeg -v debug -hide_banner -nostdin -nostats -i "00305.m2ts" -map v:0 -c rawvideo -f null -
͏ ; report the last few lines of interest.
͏ (notably "packets muxed", "packets read")
comment:161 by , 6 days ago
Replying to MasterQuestionable:
͏ Threaded mode? What is that?
See attachment: Theaded.png
It makes conversations easier to follow.
comment:162 by , 6 days ago
I sent this to you a couple of days ago. No matter... Here's the last few lines:
[in#0/mpegts @ 00000000004ddbc0] EOF while reading input [in#0/mpegts @ 00000000004ddbc0] Terminating thread with return code 0 (success) [out#0/null @ 0000000000567340] All streams finished [out#0/null @ 0000000000567340] Terminating thread with return code 0 (success) [out#0/null @ 0000000000567340] Output file #0 (pipe:): [out#0/null @ 0000000000567340] Output stream #0:0 (video): 138407 packets muxed (13492671603 bytes); [out#0/null @ 0000000000567340] Total: 138407 packets (13492671603 bytes) muxed [out#0/null @ 0000000000567340] video:13176437KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown size=N/A time=01:36:12.68 bitrate=N/A speed=41.4x [in#0/mpegts @ 00000000004ddbc0] Input file #0 (c:\00305.m2ts): [in#0/mpegts @ 00000000004ddbc0] Input stream #0:0 (video): 138407 packets read (13492671603 bytes); [in#0/mpegts @ 00000000004ddbc0] Total: 138407 packets (13492671603 bytes) demuxed [AVIOContext @ 00000000004c3a80] Statistics: 15097004176 bytes read, 2 seeks
What do you see?
follow-up: 164 comment:163 by , 6 days ago
͏ You reported "-c copy" not "-c rawvideo".
͏ You effectively undid your change.
͏ Note the command has changed.
͏ ----
͏ E.g. to understand comment:150, load everything from comment:135 - comment:165 as reference (context); and trace deeper on need.
͏ "Oldest first" recommended.
͏ Report the same for "00306.m2ts".
͏ "It makes conversations easier to follow."
<^> Maybe, may not.
follow-ups: 165 166 comment:164 by , 6 days ago
Replying to MasterQuestionable:
͏ You reported "-c copy" not "-c rawvideo".
I don't think so.
Edit: I did run it with '-c copy'. You know why? Because that's what you had in comment 141. Then, after I ran 'nostats', you changed your comment to '-c rawvideo'.
I'm also running this:
ffmpeg -v debug -copyts -hide_banner -nostdin -nostats -i c:\00305.m2ts -map v:0 -c rawvideo -f null - 2>"c:\00305.m2ts nostats-copyts.txt"
to see if preserving TSes makes a difference.
comment:165 by , 6 days ago
Results.
00305.m2ts nostats.txt = 837326 lines
[h264 @ 00000000004f0800] nal_unit_type: 10(End of sequence), nal_ref_idc: 0 [h264 @ 00000000004f0800] ct_type:1 pic_struct:0 [vist#0:0/h264 @ 0000000002b1cc80] [dec:h264 @ 0000000000487200] Decoder returned EOF, finishing [vist#0:0/h264 @ 0000000002b1cc80] [dec:h264 @ 0000000000487200] Terminating thread with return code 0 (success) [out_#0:0 @ 0000000002bafac0] EOF on sink link out_#0:0:default. [vf#0:0 @ 000000000367a7c0] Filtergraph returned EOF, finishing [vf#0:0 @ 000000000367a7c0] All consumers returned EOF [vf#0:0 @ 000000000367a7c0] Terminating thread with return code 0 (success) [vost#0:0/rawvideo @ 000000000367a040] Encoder thread received EOF [vost#0:0/rawvideo @ 000000000367a040] Terminating thread with return code 0 (success) [out#0/null @ 0000000000547340] All streams finished [out#0/null @ 0000000000547340] Terminating thread with return code 0 (success) [out#0/null @ 0000000000547340] Output file #0 (pipe:): [out#0/null @ 0000000000547340] Output stream #0:0 (video): 138407 frames encoded; 138407 packets muxed (430501132800 bytes); [out#0/null @ 0000000000547340] Total: 138407 packets (430501132800 bytes) muxed [out#0/null @ 0000000000547340] video:420411262KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown frame=138407 fps= 98 q=-0.0 Lsize=N/A time=01:36:12.72 bitrate=N/A speed=4.08x [in#0/mpegts @ 000000000047dbc0] Input file #0 (c:\00305.m2ts): [in#0/mpegts @ 000000000047dbc0] Input stream #0:0 (video): 138407 packets read (13492671603 bytes); 138407 frames decoded; 0 decode errors; [in#0/mpegts @ 000000000047dbc0] Total: 138407 packets (13492671603 bytes) demuxed [AVIOContext @ 0000000000463a80] Statistics: 15097004176 bytes read, 2 seeks
00305.m2ts nostats-copyts.txt = 824063 lines
[h264 @ 0000000002b20980] nal_unit_type: 10(End of sequence), nal_ref_idc: 0 [h264 @ 0000000002b20980] ct_type:1 pic_struct:0 [vist#0:0/h264 @ 0000000000525700] [dec:h264 @ 0000000002c50180] Decoder returned EOF, finishing [vist#0:0/h264 @ 0000000000525700] [dec:h264 @ 0000000002c50180] Terminating thread with return code 0 (success) [out_#0:0 @ 00000000063a4dc0] EOF on sink link out_#0:0:default. [vf#0:0 @ 000000000355c880] Filtergraph returned EOF, finishing [vf#0:0 @ 000000000355c880] All consumers returned EOF [vost#0:0/rawvideo @ 000000000371f9c0] Encoder thread received EOF [vf#0:0 @ 000000000355c880] Terminating thread with return code 0 (success) [vost#0:0/rawvideo @ 000000000371f9c0] Terminating thread with return code 0 (success) [out#0/null @ 0000000000497340] All streams finished [out#0/null @ 0000000000497340] Terminating thread with return code 0 (success) [out#0/null @ 0000000000497340] Output file #0 (pipe:): [out#0/null @ 0000000000497340] Output stream #0:0 (video): 138407 frames encoded; 138407 packets muxed (430501132800 bytes); [out#0/null @ 0000000000497340] Total: 138407 packets (430501132800 bytes) muxed [out#0/null @ 0000000000497340] video:420411262KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown frame=138407 fps= 95 q=-0.0 Lsize=N/A time=00:00:00.00 bitrate=N/A speed= 0x [in#0/mpegts @ 000000000051dc40] Input file #0 (c:\00305.m2ts): [in#0/mpegts @ 000000000051dc40] Input stream #0:0 (video): 138407 packets read (13492671603 bytes); 138407 frames decoded; 0 decode errors; [in#0/mpegts @ 000000000051dc40] Total: 138407 packets (13492671603 bytes) demuxed [AVIOContext @ 000000000051c180] Statistics: 15097004176 bytes read, 2 seeks
comment:166 by , 6 days ago
00306.m2ts nostats.txt = 678131 lines
[h264 @ 0000000002c0e780] nal_unit_type: 10(End of sequence), nal_ref_idc: 0 [h264 @ 0000000002c0e780] ct_type:1 pic_struct:0 [vist#0:0/h264 @ 0000000003480040] [dec:h264 @ 000000000337d9c0] Decoder thread received EOF packet [vist#0:0/h264 @ 0000000003480040] [dec:h264 @ 000000000337d9c0] Decoder returned EOF, finishing [vist#0:0/h264 @ 0000000003480040] [dec:h264 @ 000000000337d9c0] Terminating thread with return code 0 (success) [out_#0:0 @ 00000000039dd440] EOF on sink link out_#0:0:default. [vf#0:0 @ 00000000004e7280] Filtergraph returned EOF, finishing [vf#0:0 @ 00000000004e7280] All consumers returned EOF [vost#0:0/rawvideo @ 0000000002ca3d80] Encoder thread received EOF [vf#0:0 @ 00000000004e7280] Terminating thread with return code 0 (success) [vost#0:0/rawvideo @ 0000000002ca3d80] Terminating thread with return code 0 (success) [out#0/null @ 00000000005b7340] All streams finished [out#0/null @ 00000000005b7340] Terminating thread with return code 0 (success) [out#0/null @ 00000000005b7340] Output file #0 (pipe:): [out#0/null @ 00000000005b7340] Output stream #0:0 (video): 112669 frames encoded; 112669 packets muxed (350445657600 bytes); [out#0/null @ 00000000005b7340] Total: 112669 packets (350445657600 bytes) muxed [out#0/null @ 00000000005b7340] video:342232088KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown frame=112669 fps= 99 q=-0.0 Lsize=N/A time=01:18:19.23 bitrate=N/A speed=4.12x [in#0/mpegts @ 00000000004ddbc0] Input file #0 (c:\00306.m2ts): [in#0/mpegts @ 00000000004ddbc0] Input stream #0:0 (video): 112669 packets read (10790186826 bytes); 112669 frames decoded; 0 decode errors; [in#0/mpegts @ 00000000004ddbc0] Total: 112669 packets (10790186826 bytes) demuxed [AVIOContext @ 00000000004c3a80] Statistics: 12085080208 bytes read, 2 seeks
follow-up: 168 comment:167 by , 6 days ago
͏ You shall use `> "${Out}" 2>&1` instead: lest incomplete redirection.
͏ (the order matters for Unix Shell, don't invert)
͏ Also, please optimize your output accordingly:
͏ https://trac.ffmpeg.org/attachment/ticket/11055/00305.m2ts.txt#L17913
͏ .
͏ |1| Remove the memory address in output messages' header. [ See also: #10998 ]
͏ |2| Normalize In/Out names to basename. (removing `c:\` for your case)
͏ And among your output (for "00305.m2ts", "00306.m2ts") there was no:
͏ "Application provided invalid, non monotonically increasing dts to muxer in stream 0"
͏ ?
͏ Also you may name the files alike:
͏ "00305.m2ts.r.txt"
͏ "00305.m2ts.r.copyts.txt"
͏ .
͏ "nostats" is not significant option (used mostly for pretty printing).
͏ ".r", ".c" indicates being of "-c copy" or "-c rawvideo".
͏ Note: "rawvideo" is not necessarily video.
͏ "rawwhatsoever" perhaps better describes it... (or just "raw")
͏ For "-copyts" related: trace comment:11.
comment:168 by , 6 days ago
Your English is very, very confusing. I will do whatever you ask, but you have to ask. Pretend I'm stupid or a child or a machine. I am in your hands. I will be your hands.
.
͏ You shall use `> "${Out}" 2>&1` instead: lest incomplete redirection.
͏ (the order matters for Unix Shell, don't invert)
Unix shell?
Invert?
Invert means to make something upside-down
umop-dn up-down
.
͏ Also, please optimize your output accordingly:
͏ https://trac.ffmpeg.org/attachment/ticket/11055/00305.m2ts.txt#L17913
my output?
I will produce whatever output you want. Tell me what you want.
.
͏ |1| Remove the memory address in output messages' header. [ See also: #10998 ]
͏ |2| Normalize In/Out names to basename. (removing `c:\` for your case)
memory address? output messages' header?
.
͏ And among your output (for "00305.m2ts", "00306.m2ts") there was no:
͏ "Application provided invalid, non monotonically increasing dts to muxer in stream 0"
͏ ?
Give me a command. I will do whatever you want. I will send you whatever you request. I will take whatever time is needed.
.
͏ Also you may name the files alike:
͏ "00305.m2ts.r.txt"
͏ "00305.m2ts.r.copyts.txt"
͏ .
Done.
follow-up: 170 comment:169 by , 6 days ago
͏ My language of choice undergoes big data analysis and has solid linguistic base.
͏ "invert" for reference:
͏ https://en.wiktionary.org/wiki/Special:Search?ns0=1&search=invert
͏ https://www.google.com/search?hl=en&gl=ca&num=1&expnd=1&q=define:invert
͏ https://www.merriam-webster.com/dictionary/invert
͏ https://www.etymonline.com/word/invert
͏ [ Quote MasterQuestionable @ CE 2024-06-16 21:59:04 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:98
͏ Do you attempt simple Google Search alike for unrecognized terms? ]
͏ [ Quote MasterQuestionable @ CE 2024-06-18 14:19:00 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:133
͏ Search before ask, I'd suggest. ]
͏ Probably you just have some reading difficulties... No matter.
͏ comment:167 is mostly of optimization instructions.
͏ And I may speculatively guess a lot things rather accurately.
͏ It appears the origin inputs ("00305.m2ts", "00306.m2ts"; that used to generate "Ticket_11055.m2ts") may be decoded without similar problem.
͏ Bad slice mostly.
͏ Do you have further questions?
comment:170 by , 6 days ago
͏ Probably you just have some reading difficulties... No matter.
I have difficulties reading what you write, that's for sure.
͏ comment:167 is mostly of optimization instructions.
I didn't understand what you wrote.
͏ And I may speculatively guess a lot things rather accurately.
Do you care to share your speculations?
͏ It appears the origin inputs ("00305.m2ts", "00306.m2ts"; that used to generate "Ticket_11055.m2ts") may be decoded without similar problem.
It appears [that] the origin [original] inputs ("00305.m2ts", "00306.m2ts"; that [were] used to generate "Ticket_11055.m2ts") may be decoded without similar ? problem.
I did not decode 00305.m2ts or 00306.m2ts.
͏ Bad slice mostly.
"Slice" as in macroblock slice? Or slice as in cutting, as in making a clip?
͏ Do you have further questions?
Yes.
Question 1:
Why do the timestamps in this:
ffmpeg -copyts -i Ticket_11055.m2ts -map 0:v -vf showinfo -c:v rawvideo -f null -muxdelay 0 - 2>Ticket_11055.m2ts_showinfo.txt
differ from the timestamps in this:
ffmpeg -i Ticket_11055.m2ts -map 0 -copyts -c copy -dn -sn -f framecrc - >Ticket_11055.m2ts_framecrc.txt
Note that the timestamps in framecrc match the actual packets in Ticket_11055.m2ts.
Question 2:
Why do the timestamps in this:
ffprobe -sexagesimal -select_streams v -show_frames -of flat -i Ticket_11055.m2ts >Ticket_11055.m2ts_show_frames.txt
differ from the timestamps in this:
ffmpeg -i Ticket_11055.m2ts -map 0 -copyts -c copy -dn -sn -f framecrc - >Ticket_11055.m2ts_framecrc.txt
Note that the timestamps in framecrc match the actual packets in Ticket_11055.m2ts.
Thank you.
comment:171 by , 6 days ago
Why did you change the subject line to this:
"OGOP (Open GOP) in certain conditions may cause missing frames of decoding"
What is it that leads you to conclude that the problem is open GOP?
follow-ups: 173 174 comment:172 by , 5 days ago
͏ https://en.wikipedia.org/wiki/Nominal_sentence#In_English
͏ .
͏ Note it's indeed "origin".
͏ Similar problem? What is the whole thread about..?
͏ comment:112 for how "Ticket_11055.m2ts" was generated.
͏ You somehow produced the bad clip.
͏ Note:
͏ Copy & Pasted comment:143.
͏ Already answered in comment:152.
͏ .
͏ "Without B-frames: decoding, presentation order can be unified."
͏ "You seem to lack adequate understanding on the video presentation things: Notably the concept of B-frame."
͏ [ Quote MasterQuestionable @ CE 2024-06-16 13:51:48 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:82
͏ "The issue of open GOP is irrelevant"
<^> I doubt so.
͏ Otherwise where went the missing frames?
͏ (if not for such havoc)
͏ I believe those went missing are of OGOP. ]
<^> Or probably the seriously wrong timestamps caused the exception.
comment:173 by , 5 days ago
Ticket_11055.m2ts plays correctly and completely by two players that do not depend on FFmpeg.
Ticket_11055.m2ts has 99 frames. All frames are listed correctly by framecrc.
Ticket_11055.m2ts has 99 frames. All frames are listed correctly by a packet analyzer.
Ticket_11055.m2ts.xml data is wrong.
The showinfo list is wrong. It finds only 53 frames. Its timestamps are wrong.
The show_frames list is wrong. It finds only 54 frames. Its timestamps are wrong. It shows DTS>PTS.
These are facts.
When are we going to get on with the job of troubleshooting the FFmpeg timestamp bug?
I will do whatever you ask.
Thank you.
comment:174 by , 5 days ago
Replying to MasterQuestionable:
͏ comment:112 for how "Ticket_11055.m2ts" was generated.
͏ You somehow produced the bad clip.
Please show me what is bad about Ticket_11055.m2ts.
͏ [ Quote MasterQuestionable @ CE 2024-06-16 13:51:48 UTC:
https://trac.ffmpeg.org/ticket/11055#comment:82
͏ "The issue of open GOP is irrelevant"
<^> I doubt so.
͏ Otherwise where went the missing frames?
There are no missing frames. All 99 frames are there, in Ticket_11055.m2ts.
͏ I believe those went missing are of OGOP. ]
<^> Or probably the seriously wrong timestamps caused the exception.
There was no exception.
The wrong timestamps are the bug. There are no missing frames. That is the bug.
follow-up: 176 comment:175 by , 5 days ago
͏ There are significant doubts on the content you report.
͏ Regardless, enough information has been gathered through:
͏ Which may be kept for future debugging.
͏ Summary:
͏ It involves a fringe case of potential optimization.
͏ Not serious enough to wreak general havoc.
comment:176 by , 5 days ago
Replying to MasterQuestionable:
͏ There are significant doubts on the content you report.
͏ Regardless, enough information has been gathered through:
͏ Which may be kept for future debugging.
͏ Summary:
͏ It involves a fringe case of potential optimization.
͏ Not serious enough to wreak general havoc.
You have got to be kidding. Two FFmpeg functions disagree with a third FFmpeg function and with each other and it's a "fringe case"?
framecrc probably doesn't decode.
showinfo definitely does decode.
show_frames is unknown.
framecrc agrees with what's _in_the_video_, the others don't.
What could be clearer? What could be easier to trace during a test?
follow-up: 178 comment:177 by , 5 days ago
͏ Eventually, seems to only occur on your coined file.
͏ And of limited influence.
͏ You have too much misconception on how things fundamentally work.
͏ And that's beyond the scope of this issue.
comment:178 by , 5 days ago
Replying to MasterQuestionable:
͏ Eventually, seems to only occur on your coined file.
You can't know that. It could be occurring everywhere. You have no idea.
͏ And of limited influence.
You can't know that. This bug could be responsible for half of FFmpeg's errors. How important are timestamps? Would you say they are of fundamental importance?
͏ You have too much misconception on how things fundamentally work.
Cite one.
Do not insult me. You don't know me. You don't know my experience. You don't know anything about me. I engineered products and ran projects in Silicon Valley for 25 years. Does that give you a clue?
͏ And that's beyond the scope of this issue.
You cannot say anything about the scope of this issue until it is investigated.
You have not written a single word in this thread that you have backed up by fact.
.
.
When are you going to assign this to a developer?
follow-up: 180 comment:179 by , 4 days ago
͏ Just reading comment:173, comment:174 alone (plus counting the table you provided in description) would reveal enough non-sense.
͏ And dealing with alike non-sense you made up does not interest me.
͏ Based on the number of characters to determine the quality of words...
͏ And the extent of timespan to decide the effectiveness of move??
͏ One pretended asleep cannot be wakened.
͏ Facts remain, reckoned or not.
͏ ----
͏ I believe which a vain attempt to someone who cannot even properly count. ("54 frames"??)
͏ "There are no missing frames."
<^> Outright contradicting yourself.
͏ "I did not decode 00305.m2ts or 00306.m2ts."
<^> Yes, you just did somehow miraculously the "-c rawvideo" encoding out mere air.
comment:180 by , 4 days ago
Replying to MasterQuestionable:
͏ Just reading comment:173,
Here is comment 173:
Ticket_11055.m2ts plays correctly and completely by two players that do not depend on FFmpeg.
Ticket_11055.m2ts has 99 frames. All frames are listed correctly by framecrc.
Ticket_11055.m2ts has 99 frames. All frames are listed correctly by a packet analyzer.
Ticket_11055.m2ts.xml data is wrong.
The showinfo list is wrong. It finds only 53 frames. Its timestamps are wrong.
The show_frames list is wrong. It finds only 54 frames. Its timestamps are wrong. It shows DTS>PTS.
These are facts.
When are we going to get on with the job of troubleshooting the FFmpeg timestamp bug?
I will do whatever you ask.
Thank you.
What in it do you see that is wrong? Every word in it is a plain fact. Prove any of them to be wrong if you can.
comment:182 by , 4 days ago
Replying to Balling:
Where is the new file where you cut the frames...
Here are all the files:
00305.m2ts - original, 1:36:12
00306.m2ts - original, 1:27:02
00305 cut.cmd - makes 00305 cut.m2ts
00306 cut.cmd - makes 00306 cut.m2ts
00305+00306.cmd - makes 00305+00306.m2ts
Ticket_11055.m2ts - uploaded to trac
What would you like, Balling?
Also, would you like to see a timestamped diagram showing how I made both sides of the join IDR frames?
Also, PCRs on both sides of the join look correct.
Also, I've discovered the existence of splicing_point_flag, seamless_splice_flag, splice_type, and DTS_next_AU. Only splicing_point_flag is shown by DVB Inspector and MPEG-2 TS Packet Analyzer.
The I frame on the early side of the join is in packet 21156.
The I frame on the late side of the join is in packet 28186.
comment:183 by , 3 days ago
Hey, Balling,
This is what I'm doing:
::
PTS order ..P I B B P B B I I B B P..
/ ______/ ______/ / ______/
/ / / / /
DTS order ..I P B B I B B I P B B..
The splice is marked '::'.
.
This part is from 00305.m2ts.
PTS order ..P I B B P B B
/ ______/
/ /
DTS order ..I P B B B B
.
This part is also from 00305.m2ts.
PTS order I
______/
/
DTS order I
.
This part is from 00306.m2ts
PTS order I B B P..
/ ______/
/ /
DTS order I P B B..
but before I moved the I's DTS, it was like this:
PTS order I B B P..
______/ ______/
/ /
DTS order I P B B..
.
Now, cutting that I's decode time might not be wise -- Is it? -- but it can't cause the symptoms I'm seeing, can it?
comment:184 by , 3 days ago
Ticket_11055.m2ts is not a valid coded video sequence because it has no IDR pictures
ffrobe/ffmpeg often misidentifies non-key "i" as IDR. All entries of ffprobe show_frames key_frame=1 on this sample are wrong
You can verify with a stream analyzer tool such as Elecard Streameye, Codec Visa .
A free way to verify IDR frames (in display order) you have an Nvidia card is DGIndexNV, you can open the dgi file in a text editor. The IDR identification results correspond to professional stream analyzer results
There are frame_num, POC violations - likely errors in processing from misidentification improperly cut GOPs
follow-up: 188 comment:185 by , 3 days ago
Pdr0, is not there is a recovery point in the start? Elecard 2023 says so.
"However, according to the spec (08/21; annex D.2.8), this recovery point SEI may have a flag exact_match=1, which means "if you start decoding here, you get exactly the same frames, as if you started decoding at the previous IDR."
follow-up: 190 comment:186 by , 3 days ago
͏ As for FF-series tools' misidentification, would it because the peculiarity of this file:
͏ That caused FF-* to practically regard all alike "i" as "I"?
͏ Context of comment:185:
͏ https://stackoverflow.com/questions/75635925
͏ https://trac.ffmpeg.org/ticket/5309#comment:16
follow-up: 189 comment:188 by , 3 days ago
Replying to Balling:
Pdr0, is not there is a recovery point in the start? Elecard 2023 says so.
"However, according to the spec (08/21; annex D.2.8), this recovery point SEI may have a flag exact_match=1, which means "if you start decoding here, you get exactly the same frames, as if you started decoding at the previous IDR."
Yes, but it's still not a valid sequence as per the ITU h264 specs
7.4.1.2.2
"A bitstream conforming to this Recommendation | International Standard consists of one or more coded video sequences. The first access unit of each coded video sequence is an IDR access unit."
To clarify that the above applies to decoding order, not display order:
3.64
"The first picture of each coded video sequence in decoding order is an IDR picture."
As for the other issues, eg. the 1st frame in coded order specifies a frame_num of 227 and pic_order_count_lsb as 362 in this 99 frame sample... another issue is the values are supposed to increase in decoding order according to the specs, but there are examples where they decrease. This might be contributing to some of the problems observed with ffmpeg timestamps
follow-up: 191 comment:189 by , 2 days ago
Replying to pdr0:
May I respond here?
As for the other issues, eg. the 1st frame in coded order specifies a frame_num of 227 and pic_order_count_lsb as 362 in this 99 frame sample...
Oh, dear. Where can I see that, and how can I fix it? ...You see, I don't know how to parse M2TSes.
another issue is the values are supposed to increase in decoding order according to the specs, but there are examples where they decrease.
Oh, dear, again. Decreasing DTS is obviously very bad. I thought I checked every DTS. Can you show me where in my composite listing DTS decreases (or just give me the DTS value).
Despite all that, I still don't see why showinfo and show_frames report DTSes & PTSes that don't exist.
Thanks -- Mark.
follow-up: 192 comment:190 by , 2 days ago
Replying to MasterQuestionable:
͏ As for FF-series tools' misidentification, would it because the peculiarity of this file:
The question I ask and have always asked is how can framecrc and showinfo ever be different? At what point in the logic of showinfo does it change the value of TSes? At what point, and why?
The next question is how can framecrc and show_frames ever be different? At what point in the logic of show_frames does it change the value of TSes? At what point, and why?
The next question is how can showinfo and show_frames ever disagree?
Logic dictates that all 3 functions should report the exact same TSes: The TSes that I created. Why? Because they are the only TSes that exist.
comment:191 by , 2 days ago
Replying to markfilipak:
Replying to pdr0:
May I respond here?
As for the other issues, eg. the 1st frame in coded order specifies a frame_num of 227 and pic_order_count_lsb as 362 in this 99 frame sample...
Oh, dear. Where can I see that, and how can I fix it? ...You see, I don't know how to parse M2TSes.
The issues with POC, frame_num are for the AVC/h264 elementary bitstream, not for m2ts specifically. If you demux to elementary video stream, the problems remain - this is likely from improper cuts and handling
You can use one of video stream analyzers such as the ones listed above, I'm sure there are several others, newer ones. I'm not up to date on all the tools . I just know ffmpeg/ffprobe has long standing issues with IDR identification, and when you make bad cuts and joins, problems happen
another issue is the values are supposed to increase in decoding order according to the specs, but there are examples where they decrease.
Oh, dear, again. Decreasing DTS is obviously very bad. I thought I checked every DTS. Can you show me where in my composite listing DTS decreases (or just give me the DTS value).
frame_num specifies the decoding order and should never decrease. You need a parser which can examine slice headers. e.g. in stream decoding order frame 25 has a frame_num of 243, but frame 26 has a frame_num of 228 . I suspect this is from bad cuts/appending .
I wouldn't waste too much time on this. If you can demonstrate errors with a valid stream, then it should be investigated farther
follow-up: 195 comment:192 by , 2 days ago
Replying to markfilipak:
The question I ask and have always asked is how can framecrc and showinfo ever be different?
ie. Why does showinfo abort early/ return EOF, with only 53 frames , when there are 99 coded frames ?
framecrc exerpt
[in#0/mpegts @ 00000088c45fcb00] Input stream #0:0 (video): 99 packets read (14236691 bytes); 53 frames decoded; 0 decode
It might be that -vf showinfo is running it through the decoder, not just counting packets. If you swap the decoder (e.g. if you have nvidia card) it shows different information with 97 frames for -vf showinfo. Some errors in the video bitstream might be causing early termination in the filtergraph for the default SW decoder, when other decoders might handle it differently
(sorry, this is a windows cmd)
ffmpeg -report -c:v h264_cuvid -i Ticket_11055.m2ts -vf showinfo -c:v rawvideo -f null -
exerpt of showinfo using cuvid decoding
[in#0/mpegts @ 000000f6fbf4ce40] Input stream #0:0 (video): 99 packets read (14236691 bytes); 97 frames decoded; 0 decode errors;
Why only 97 frames ? I believe it's the way ffmpeg handles missing information. The 1st 2 frames in display order are missing information and are dropped by ffmpeg - Some applications place duplicates for those error frames, others drop them - it's application dependent. The nvdec decoder itself returns 99 frames. e.g. if you use LSmash decoder="h264_cuvid" or DGDecNV with avisynth or vapoursynth, the 2 error frames are kept as duplicate placeholder frames. Framecount has sync implications when you cut/append streams. (But those errors shouldn't be there in the first place had the stream processed properly.)
comment:193 by , 46 hours ago
I took Ticket_11055.m2ts and made a video consisting of one frame: I. It is noteworthy that the frame is listed by all 3 methods. That is not true of that frame when there is 99 frames.
DTS = "N/A" (marked below) is also noteworthy.
Would you like me to try with 4 frames: I B B P? Then 6 frames: I B B P B P? Then 8 frames: I B B P B P B P? Et cetera?
.
A video consisting of one frame:
framecrc 0, 504126135, 504137396, 3753, 640646, 0x9e6e8012 showinfo n: 0 pts:504137396 pts_time:5601.526622 duration: 3753 duration_time:0.0417 fmt:yuv420p cl:left sar:1/1 s:1920x1080 i:P iskey:1 type:I checksum:58F7CCBB plane_checksum:[05982AD8 A216635F 3F973E84] mean:[19 129 129] stdev:[8.9 2.7 1.3] show_frames frames.frame.0.key_frame=1 frames.frame.0.pts=504137396 frames.frame.0.pkt_dts="N/A" <<== ? frames.frame.0.best_effort_timestamp=504137396 frames.frame.0.pict_type="I" frames.frame.0.interlaced_frame=0 frames.frame.0.top_field_first=0 frames.frame.0.repeat_pict=0
follow-up: 197 comment:194 by , 45 hours ago
just know ffmpeg/ffprobe has long standing issues with IDR identification
Recovery frames are tagged as keyframes because THEY are keyframes.
I imagine if we get avc stream in a file it should warn that first frame is not IDR (there are 2 types of IDR in AVC spec). But in the stream it is useless, the stream can start with any keyframe, of course.
comment:195 by , 45 hours ago
Replying to pdr0:
Replying to markfilipak:
The question I ask and have always asked is how can framecrc and showinfo ever be different?
ie. Why does showinfo abort early/ return EOF, with only 53 frames , when there are 99 coded frames ?
I think the more interesting question is: Why are there gaps (DTS discontinuities) in the showinfo and show_frames listings?
comment:196 by , 45 hours ago
Ahem... I managed 29 projects in Silicon Valley over 25 years. I was Mr. Hardware and Mr. System. Codesmiths worked for me -- that's typical in combined HW-SW projects. Part of my job was breaking their code. I could usually break their code in less than a minute.
Does FFmpeg have people dedicated to testing?
comment:197 by , 43 hours ago
Replying to Balling:
just know ffmpeg/ffprobe has long standing issues with IDR identification
Recovery frames are tagged as keyframes because THEY are keyframes.
But "keyframe" (as identified by ffmpeg) are not necessarily IDR - nal_type_unit = 5 . And "I" frames (as identifed by ffmpeg) are not necessarily IDR.
Some people misinterpret that when ffmpeg identifies a "keyframe" and think that is a valid cut point . But when you cut/append on non IDR boundaries, problems happen
comment:198 by , 43 hours ago
Hang on...
I created Ticket_11055.m2ts, 4 seconds, by cutting 00305+00306.m2ts, 2+ hours. My interest of course was the splice in the middle of Ticket_11055.m2ts.
I used '-ss' '-to' for the cutting.
I now see that using '-ss' was a bad move by me. I will now do a clean cut and, if there are problems with that 4 second video, I'll submit a new trac ticket that's specific to that case.
In the mean time, this ticket has great value. I believe it shows that '-ss' does not produce a good frame sequence. I believe it shows that showinfo and show_frames are changing TSes when they should not change TSes.
But ticket 11055 is not relevant to my project. If you want me to do something to further ticket 11055, I will. Otherwise, I'm ending my participation.
Good Hunting -- Mark.
follow-ups: 200 202 comment:199 by , 32 hours ago
͏ So simply put... Everything that uses OGOP (Open GOP) is potentially broken.
͏ Havoc for the buggy standards.
͏ To M. markfilipak:
͏ I believe you have no idea what makes B-frame.
͏ So constantly again and again asserting the non-sense that DTS, PTS shall be regardless identical...
͏ And please don't again Copy & Paste previous posts to requestion.
͏ If you are looking for argument: I did update my posts of relevant context.
comment:200 by , 30 hours ago
Replying to MasterQuestionable:
͏ So simply put... Everything that uses OGOP (Open GOP) is potentially broken.
͏ Havoc for the buggy standards.
I sampled 10 Blu-ray movies in addition to the Criterion, Ingmar Bergman box set. Here are the ten with their barcodes.
Open GOP
A CLOCKWORK ORANGE [1971] 085391156741 [2007] ALL ABOUT EVE [1950] 024543948223 01 [2010] AMADEUS [2001] 883929036882 [2009] CAMELOT [1967] 883929219902 [2012] LE MANS [1971] 7332431036079 [2016] STAR TREK BEYOND [2016] 032429252333 [2016] SULLY [2016] 883929680887 [2016]
Closed GOP
BIG NIGHT [1996] 9344256022036 [2021] PREDESTINATION [2013] 043396439139 [2015]
No B-frames
SHERLOCK HOLMES [2009] 883929331840 [2012]
Hollywood sure is putting out a lot of broken open GOP products, eh?
.
͏ To M. markfilipak:
͏ I believe you have no idea what makes B-frame.
͏ So constantly again and again asserting the non-sense that DTS, PTS shall be regardless identical...
B-frames on DVD & Blu-ray do not have DTSes that I've ever seen, but it is FFmpeg that lists them as identical, not me.
You're really a piece of work.
comment:201 by , 24 hours ago
͏ All rationale has been explained before.
͏ (whether OGOP, DTS, B-frame: right in this thread; do trace deeper)
͏ I do not wish to pointlessly repeat.
͏ While the industries maybe more focused on practicalness. (thus without deep learning the design)
͏ My focus is theoretical superiority, unparallel.
͏ ----
͏ The sophistry cannot be justified... This thread also has the context of the OGOP thing.
comment:202 by , 23 hours ago
Replying to MasterQuestionable:
͏ So simply put... Everything that uses OGOP (Open GOP) is potentially broken.
͏ Havoc for the buggy standards.
They are potentially broken only if you handle them improperly (such as cuts/edits not along IDR boundaries) and the stream no longer complies with specifications.
If you don't "like" where the position of the cutpoints are , then you must re-encode that affected IDR=>IDR section - this is what commercial "smart rendering tools" do.
follow-ups: 204 205 comment:203 by , 17 hours ago
"pdr0 & Balling at
trac.ffmpeg.org hint that key frames are specific I-frames"
Keyframes are only when you clean start from it. In Open GOP by definition you can have a situation where some after I frames or its slices you can have dependence on frames before that I frame, thus that is non IDR frame/slice. Moroover, some frames can still be cleanly decoded even though we have that and are marked as recovery frames with exact_match=1 like in your example, moreover some frames are tagged as just recovery that allows to get after some frames to the same stream .
See, for example, https://bitmovin.com/vvc-open-gop-resolution-switching
comment:204 by , 14 hours ago
Replying to Balling:
"pdr0 & Balling at
trac.ffmpeg.org hint that key frames are specific I-frames"
Keyframes are only when you clean start from it. In Open GOP by definition you can have a situation where some after I frames or its slices you can have dependence on frames before that I frame ...
Then it can't be an I-frame. I've seen some people 'talk' about SI-frames. Show me a specification on it. Show me an MPEG tag for it.
Thank you for the link to the bitmovin article. It seemed like hogwash to me. It seemed totally conceptual, notional, not practical, not specific, not real.
I'll give my latest take on IDR frames: They don't exist, per se. What I think an IDR frame is, is an ordinary I-frame, open or closed GOP, that follows a closed GOP.
closed GOP _____ _________ An IDR frame
DTS order ..B B P I P B B P..
^^^^^
open GOP _____ _________ Not an IDR frame
DTS order ..B B I P B B P..
^^^
The difference is here
Now, in MPEG-2 TSes, there may be an MPEG tag that forces the previous GOP to _become_ a closed GOP, but I doubt it because that would require all decoders to buffer all B-frames up to the next P- or I-frame and to then throw them away if the next I-frame said "IDR"! That defeats the purpose of open GOP, and, besides that, what's on the screen in the meantime? Nothing? A picture repeat? No, no, no.
comment:205 by , 14 hours ago
Replying to Balling:
"pdr0 & Balling at
trac.ffmpeg.org hint that key frames are specific I-frames"
Keyframes are only when you clean start from it. In Open GOP by definition you can have a situation where some after I frames or its slices you can have dependence on frames before that I frame, thus that is non IDR frame/slice. Moroover, some frames can still be cleanly decoded even though we have that and are marked as recovery frames with exact_match=1 like in your example, moreover some frames are tagged as just recovery that allows to get after some frames to the same stream .
See, for example, https://bitmovin.com/vvc-open-gop-resolution-switching
For an encoded stream, yes, - that's the whole point of using open GOP
But not when you edit . When the 2nd segment does not start with IDR , there is no reset to frame_num . You get the problems that you see here
e.g.
If you have frame_num 0,1,2,3,4 for part a , but 3,4,5,6 for part b (because not on IDR) , the frame_num decreases from 4 to 3 in decoding order this is a clear spec violation
follow-up: 207 comment:206 by , 9 hours ago
Then it can't be an I-frame.
It is. I frame can still be decoded fully. It does not depend on anything.
I've seen some people 'talk' about SI-frames
Slice_type 4, yes https://stackoverflow.com/a/22559278
But can be also 7, 2 and 9.
comment:207 by , 5 hours ago
Replying to Balling:
Help me out.
"In Open GOP by definition you can have a situation where some after I frames or its slices you can have dependence on frames before that I frame ..."
Do you mean the 'open Bs' that come after the I-frame's DTS?
..open———————————> <—————————..
PTS order B B P B B I B B P
______/ ______/
/ /
DTS order P B B I B B P B B
open Bs
I tried a couple of times to upload the video clip to https://streams.videolan.org/upload/ but it doesn't appear here. I give up.