PTS jumping backwards in H.264 video in MPEG TS container

[raj2569]

Hi,

I am decoding a video stream produced by vlc (v2.2.0) with "RTP/MPEG Transport Stream" destination and H.264+MP3 (MP4) profile.

I have written program to extract and decode PTS from the stream. My understanding was that PTS will increase monotonously while DTS can have negative values for B frames.

How ever I can see that for some packets, the PTS jumps backwards. Is it allowed? The packet dump and my program's debug output is attached below:

2015-11-27 14:33:22,632 __main__ INFO 2806 raw PTS is 3F D885 AC33 at 13
2015-11-27 14:33:22,632 __main__ INFO 2806 decoded PTS is 4129379865 at 13
Start of dump of packet 2806
47404919 000001E0 178D80C0 0A3FD885
AC331FD8 85544F00 00000109 E0000000
01419BE6 49E10F26 53053FFF D84A1696
2738EE4D 576CBE9E 6D5454E5 9C24E917
5AC85609 AA8D919F 948E76ED 8D4D29F7
F62F7D19 AC608AC2 52553FD2 EF75676A
FCA5F229 DD70C688 45B14305 CA5C1CA7
1C535CFE AF480E83 972434C0 F85760C5
38A8F426 E8FFF301 BA6CF0D5 AAB7BAA1
3D68A339 8DD6CBEB B085F617 5284748D
6D011B59 ACAE9555 D66F76D7 5C7D51E2
82AD97B8 09D79CCB AE26E447 00000000
2015-11-27 14:33:22,632 __main__ INFO Pkt count: 2806 index: 805 time_diff 125 pts_in_ms: 45881998

2015-11-27 14:33:22,633 __main__ INFO 2845 raw PTS is 3F D885 8EE7 at 13
2015-11-27 14:33:22,633 __main__ INFO 2845 decoded PTS is 4129376115 at 13
Start of dump of packet 2845
4740491A 000001E0 097680C0 0A3FD885
8EE71FD8 85719B00 00000109 E0000000
01019E05 6A4DFFEF A679BB3B 48BEBD31
5A40489F 9FAB8554 0D3F252C 84F4571A
1031C88A A3CE3081 C477AC5F 8C06D0D0
79F68705 7492EE10 B1B634FF E6AE4041
E5302B3E 82D6CB8D D94DBC2F F1E1CA05
283C39BE 287D65DA 074D4052 2D29A309
7BF22318 8E5CE4AC C4315660 B525C371
2938638E 6A75E683 E2508650 73B736F0
44736875 5D3E66E4 5E658848 54DDB7CB
F36A6E68 2EA6B4D8 5B229430 00000000
2015-11-27 14:33:22,633 __main__ INFO Found negative PTS difference -42
2015-11-27 14:33:22,633 __main__ INFO Pkt count: 2845 index: 844 time_diff -42 pts_in_ms: 45881956


The PTS value decoded for packet 2806 from raw bytes 3F D885 AC33 is 4129379865 and that for packet 2845 is 3F D885 8EE7 and 4129376115 respectively. The difference is -3750 which when divided by 90 gives -41.6 (marked as green). The pts_in_ms value is pts/90.

Since this is produced by vlc, the incoming stream must be legal and proper, but I am unable to figure out what is wrong.

[Sulik]

this is normal: frame decode order (dts) != frame display order (pts).
DTS should increase but PTS can go backwards before the decoder, while it's the opposite when it reaches the renderer.

[foxyshadis]

It's easier to not mix up decode/display (I have that problem too!) if you remember PTS is presentation timestamp.

[raj2569]

Thanks Sulik and foxyshadis,

Originally Posted by Sulik

DTS should increase but PTS can go backwards before the decoder, while it's the opposite when it reaches the renderer.

Just to clarify, DTS should be monotonously increasing with no jumping back when H.254 is in MPEG-TS container?

[foxyshadis]

The TS can have practically anything in any order, thanks to retransmissions and the like; although in-order is normal, have to use the continuity counter and PCR to be completely sure. Only the underlying PES or ES is guaranteed to be monotonically increasing, once you've reconstructed it.

However, for in-order frames like the absence of B-frames, a DTS isn't even supposed to be present (since DTS=PTS), and if SVC or MVC is in use, DTS (and PTS) may repeat for each piece that belongs to a single frame.

[raj2569]

Originally Posted by foxyshadis

The TS can have practically anything in any order, thanks to retransmissions and the like; although in-order is normal, have to use the continuity counter and PCR to be completely sure. Only the underlying PES or ES is guaranteed to be monotonically increasing, once you've reconstructed it.

Thanks again for the nice explanation!