Opened 3 months ago
Last modified 2 months ago
#11136 new defect
FFprobe DTS and documentation errors
| Reported by: | markfilipak | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | ffprobe |
| Version: | git-master | Keywords: | ffprobe DTS docs |
| Cc: | MasterQuestionable | Blocked By: | |
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Thank you for considering this report. As you will see, '-show_frames' says PTS = DTS = 25257 for frame.0. That is incorrect.
Command: ffprobe -flags2 +showall -sexagesimal -analyzeduration 240000000 -probesize 1000000000 -select_streams v -show_frames -of flat -i y:\VIDEO_TS\VTS_01_1.VOB
C:\Windows\System32>ffmpeg -version
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
This is the final version that runs in Win7.
I tried to extract 5 seconds of y:\VIDEO_TS\VTS_01_1.VOB but not even '-copyts' would stop FFmpeg changing TSes. So, I made a binary copy of the first 4 frames that is suitable for examining with a hex editor in order to confirm what I've written below. I saved it as 'FFprobe DTS and documentation errors.bin'.
The following are extracts of the FFprobe output annotated by my parse of y:\VIDEO_TS\VTS_01_1.VOB.
frames.frame.0.pts=25257
frames.frame.0.pkt_dts=25257
frames.frame.0.pict_type="I"
0x84E: 00 00 01 00 00 0A <== is I
0x80E: 00 00 01 E0 07 EC 81 C1 0D 31 00 01 C5 53 11 00 01 AD DD
0x80E: == == == == == == == C1 == == == == == == == == == == ==
.———''——.
PTS_DTS_flags 11-- ----
0x80E: == == == == == == == == == 31 00 01 C5 53 == == == == ==
.—————————————————' '————————————————.
marker bits 0011 1 1 1
PTS 000 0000 0000 0000 000 1100 0101 0101 001 <== 25257
0x80E: == == == == == == == == == == == == == == 11 00 01 AD DD
.—————————————————' '————————————————.
marker bits 0001 1 1 1
DTS 000 0000 0000 0000 000 1010 1101 1101 110 <== 22254
+------------------------------------------+
¦ ERROR #1: FFprobe reports the wrong DTS. ¦
+------------------------------------------+
frames.frame.3.pts="N/A"
frames.frame.3.pkt_dts=34266
frames.frame.3.pict_type="P"
0x1016B: 00 00 01 00 00 D2 <== is P
0x1000E: 00 00 01 E0 07 EC 81 00 <== no PTS or DTS
frames.frame.1.pts=28260
frames.frame.1.pkt_dts=28260
frames.frame.1.pict_type="B"
0x16507: 00 00 01 00 00 5A <== is B
0x1600E: 00 00 01 E0 07 EC 81 00 <== no PTS or DTS
frames.frame.2.pts=31263
frames.frame.2.pkt_dts=31263
frames.frame.2.pict_type="B"
0x1AB5F: 00 00 01 00 00 9A <== is B
0x1A80E: 00 00 01 E0 07 EC 81 00 <== no PTS or DTS
Of course I have no idea why there's no PTSes. FFmpeg and MPV seem to be doing the only sensible thing they could do in such a situation. However...
+--------------------------------------------------------------------------------------------+ ¦ ERROR #2, documentation: ¦ ¦ I noticed that '-show_frames' is in PTS order. That's pretty vital information that's not ¦ ¦ shown in the docs. The doc says: ¦ ¦ "-show_frames ¦ ¦ "Show information about each frame and subtitle contained in the input multimedia stream." ¦ ¦ The "input multimedia stream", eh? Then the '-show_frames' frames should be in DTS order, ¦ ¦ shouldn't they? The correct thing would be to list the frames in DTS order and add a ¦ ¦ helpful note to the doc stating why they are in DTS order. ¦ +--------------------------------------------------------------------------------------------+
Kindly let me know if I can be of further service.
Thanks--Mark.
Attachments (1)
Change History (11)
by , 3 months ago
| Attachment: | FFprobe DTS and documentation errors.bin added |
|---|
follow-up: 4 comment:1 by , 3 months ago
comment:2 by , 3 months ago
Reading wikipedia on https://en.wikipedia.org/wiki/Packetized_elementary_stream
If only PTS is present, this is done by catenating 0010b, most significant 3 bits from PTS, 1, following next 15 bits, 1, rest 15 bits and 1. If both PTS and DTS are present the same is done, but first 4 bits before start of PTS bits are 0011b (and not 0010b) and first 4 bits before start of DTS bits are 0001b. Other appended bytes have similar but different encoding.
marker bits 0001 1 1 1 DTS 000 0000 0000 0000 000 1010 1101 1101 110 <== 22254
So extracting the DTS we indeed get 22254
follow-up: 5 comment:3 by , 3 months ago
Of course I have no idea why there's no PTSes
That is simple, only one time it says
PTS_DTS_flags: 3
all others say
PTS_DTS_flags: 0
follow-up: 10 comment:4 by , 3 months ago
Replying to Balling:
00 00 01 00 00 0A
Is actually decoded:
0084E Header (4 bytes) 0084E synchro: 1 (0x000001) 00851 start_code: 0 (0x00) 00852 temporal_reference: 0 (0x000) - (10 bits) 00853 picture_coding_type: 1 (0x1) - (3 bits) - I 00853 vbv_delay: 24078 (0x5E0E) - (16 bits)
Of course, though I like my parses better because you can see the actual bits, like a hex dump, instead of 'beautified' values with no physical link.
would stop FFmpeg changing TSes
This is not MPEG-TS/ M2TS.
Of course not.
It is PES.
From a VOB, as I show in the command.
It is a very different structure, which you can see in Wireshark, though it stops at parsing MPEG quantisation matrix, but that is parsed by Elecard. It has closed_gop flag set. Nice, also has time code at 1 hour and as we can see in Mediatrace other things.
'FFprobe DTS and documentation errors.bin' is not from a network stream. It is the first 4 frames of the VOB.
says PTS = DTS = 25257
Yep, Elecard says DTS is 22254, interesting. Does not matter though.
It certainly does matter. I hope you're not planning to ignore it. I used to rely on FFprobe. No longer. I can't trust FFmpeg.
First of all first frame in the hex edit I see is actually I frame then P, then B, B.
Of course. I used to trust FFprobe and thought that some PESes were received in PTS order. I suspected that FFmpeg is intentionally misleading. That was back in the days when I thought FFmpeg wrote the coder code. Now I see the truth.
Again, that needs to be decoded to 00:00:00.247. we see in Mediatrace:
00817 PTS - 00:00:00.281 (5 bytes) 00817 PTS_32: 0 (0x0) - (3 bits) 00818 PTS_29: 0 (0x0000) - (15 bits) 0081A PTS_14: 25257 (0x62A9) - (15 bits) 0081C DTS - 00:00:00.247 (5 bytes) 0081C DTS_32: 0 (0x0) - (3 bits) 0081D DTS_29: 0 (0x0000) - (15 bits) 0081F DTS_14: 22254 (0x56EE) - (15 bits)
So, you agree that FFprobe is wrong. Will it be fixed?
I noticed that '-show_frames' is in PTS order. That's pretty vital information that's not shown in the docs
since show_frames has pts increasing and dts chaotic it is obvious.
It is obvious to you! It is unreasonable to assume others will parse and see the order is actually DTS order. It is misleading for a probe of an input stream to show that stream in PTS order when it is not in PTS order. What is the point of misleading people?
I hope you don't argue with me.
comment:5 by , 3 months ago
Replying to Balling:
Of course I have no idea why there's no PTSes
That is simple, only one time it says
PTS_DTS_flags: 3
all others say
PTS_DTS_flags: 0
Duh? No. That is why no PTS or DTS is shown. I have no idea why there is no TSes. I have no idea what tool Paramount used in 2010. It just seems strange to me, as I'll bet it seems strange to you.
Please tell me what it is about what you write that has anything to do with FFprobe getting the DTSes of the I-frames wrong. FFmpeg is making up PTSes for the B-frames, but shows N/A for each and every P-frame. I ran into two of these monstrosities in a row, on the same day.
follow-up: 7 comment:6 by , 3 months ago
#10408. So it fact while it shows frames in PTS order it has crazy bugs like this where it can print wrong pts on them. Wow.
comment:7 by , 3 months ago
Replying to Balling:
Why are you showing me that ticket? What does it have to do with this ticket?
comment:8 by , 3 months ago
Assuming dts values are monotonic, the order is PTS. If the dts are not monotonic the order is not garanteed to be PTS.
comment:10 by , 2 months ago
| Cc: | added |
|---|
͏ "It is misleading for a probe of an input stream to show that stream in PTS order when it is not in PTS order."
<^> It is misleading because you don't seem to quite understand the essence of video:
͏ The media delivers what the media intended, not its implementation.
͏ For the B-frame things that have things disordered, the end viewers typically don't care.
This is not MPEG-TS/ M2TS. It is PES. It is a very different structure, which you can see in Wireshark, though it stops at parsing MPEG quantisation matrix, but that is parsed by Elecard. It has closed_gop flag set. Nice, also has time code at 1 hour and as we can see in Mediatrace other things.
Yep, Elecard says DTS is 22254, interesting. Does not matter though. First of all first frame in the hex edit I see is actually I frame then P, then B, B.
Again, that needs to be decoded to 00:00:00.247. we see in Mediatrace:
since show_frames has pts increasing and dts chaotic it is obvious.