#11136: FFprobe DTS and documentation errors
-------------------------------------+-------------------------------------
Reporter: markfilipak | Owner: (none)
Type: defect | Status: new
Priority: normal | Component: ffprobe
Version: git-master | Resolution:
Keywords: ffprobe DTS | Blocked By:
docs |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by markfilipak):
Replying to [comment:1 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.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11136#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker_______________________________________________
FFmpeg-trac mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
