[FFmpeg-trac] #11080(documentation:new): FFmpeg timestamps do not consistently agree with packet timestamps

[FFmpeg]

#11080: FFmpeg timestamps do not consistently agree with packet timestamps
-------------------------------------+-------------------------------------
             Reporter:  markfilipak  |                    Owner:  (none)
                 Type:  task         |                   Status:  new
             Priority:  normal       |                Component:
                                     |  documentation
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by markfilipak):

 First, does FFmpeg have dedicated testers?

 Second, I'll reply to what I assume has been directed to me.

 Replying to [comment:77 Balling]:
 > Second of all, stop sending all that stuff to ffmpeg-user list, they do
 not know what they are talking about except Paul and Michael.

 No worry... I hoped that Gyan would join in, too. If others contribute
 foo, I can correct them.

 > This file has no mixed slices.

 Mind you, I know about I- SI- P- SP- and B-slices. By "no mixed slices",
 do you mean all frames have only I-slices and SI-slices? If so, how do you
 know that? What tool?

 > This IS A BLU-RAY, the spec per H.264 on Blu-ray ...

 The pattern: /blu-ray/ig, doesn't appear in H.264. Do you mean H.264,
 Annex B?

 >... requires 4 slices on each frame ...

 By "4 slices" do you mean reference slices or reconstructed slices? How do
 you know what you say? What tool?

 > Finally, I think I found the real issue here: see analyser, why is this
 P frame recogized somewhere in the second cut of frames??? BOTH 2
 analyzers behave like this:
 >
 > Let's open a new bug about how it cannot decode BBI if you cut two first
 B frames, maybe because of that frame!! https://i.imgur.com/DcWUnnz.png
 This frame PTS 13 (and logically it should be there) yet it places it
 somewhere in the end.

 I respectfully disagree with your reckoning that the open Bs (i.e. in DTS:
 I B B) are, all three, part of a single GOP. I contend that the open Bs
 are part of the previous GOP that was cut off. I also respectfully
 disagree that I- & B-frames and GOPs exist in AVC -- they do not appear in
 the text, not at all. That makes 'talking' about them impossible.

 My concern is NAL AU-1 (aka "non-IDR" frame) and NAL AU-5 (aka "IDR"
 frame). I- P- & B-frames are a fiction. GOPs are fiction in AVC.

 About tools: I use 5 tools: H.222, H.264, a hex editor, Eric Berendsen's
 DVBinspector, and Peter Daniel's MPEG-2 TS Packet Analyser [sic]. I rely
 mostly on the first three. I've found the beautifications that tools make
 hide the truth and also hide their bugs. DVBinspector is problematical. A
 hex editor never lies. Here is an example of my parsing:

 {{{
 ======================================| TS PACKET
   0..3   TS header                    | 47 HH HH HH
          sync_byte                    | 47 == == ==
                                       | == HH HH H=
                                       | .——'     '—————————————.
          transport_error_indicator    | b--- ---- ---- ---- ----
          payload_unit_start_indicator | -b-- ---- ---- ---- ----
          transport_priority           | --b- ---- ---- ---- ----
 //0,none..1,for this PID, this packet has priority over others with '0'
 transport_priority
          PID (Packet Identifier)      | ---b bbbb bbbb bbbb ----
 //0,PAT..1,CAT..2,TS description
 table..3,IPMP..4..15,(reserved)..16..8190,network_PID Program_map_PID
 elementary_PID or other..8191,packet is null -- may also convey PCR
          transport_scrambling_control | ---- ---- ---- ---- bb--
 //0,payload is not scrambled..1..3,(user-defined)
          adaptation_field_control     | ---- ---- ---- ---- --bb
 //0,(reserved)..1,has payload..2,has adaptation..3,has adaptation+payload
          continuity_counter           | == == == =H              //0..15
 --------------------------------------|
 TS_PAYLOAD_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
   4..187                              |
 //PS..PES..stuffing bytes..private data
 }}}
 And one last thing: Can you help me find where NAL units live? I can't
 find them in the H.264 syntax.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11080#comment:80>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker