Opened 4 months ago

Last modified 4 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)

FFprobe DTS and documentation errors.bin (122.0 KB ) - added by markfilipak 4 months ago.

Download all attachments as: .zip

Change History (11)

by markfilipak, 4 months ago

comment:1 by Balling, 4 months ago

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)

would stop FFmpeg changing TSes

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.

says PTS = DTS = 25257

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:

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)

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.

comment:2 by Balling, 4 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

comment:3 by Balling, 4 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

in reply to:  1 ; comment:4 by markfilipak, 4 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.

in reply to:  3 comment:5 by markfilipak, 4 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.

comment:6 by Balling, 4 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.

in reply to:  6 comment:7 by markfilipak, 4 months ago

Replying to Balling:

Why are you showing me that ticket? What does it have to do with this ticket?

comment:8 by Balling, 4 months ago

Assuming dts values are monotonic, the order is PTS. If the dts are not monotonic the order is not guaranteed to be PTS.

Last edited 4 months ago by Balling (previous) (diff)

comment:9 by Balling, 4 months ago

Duplicate of #2375

in reply to:  4 comment:10 by MasterQuestionable, 4 months ago

Cc: MasterQuestionable 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.

Version 0, edited 4 months ago by MasterQuestionable (next)
Note: See TracTickets for help on using tickets.