8

I have an MPEG2 TS file and now I am interested in extracting PTS information from each picture frame. I know that PTS is described in 33 bits including 3 marker bits. But I don't know how this bitfield can be converted to more understandable form (seconds, milliseconds). Can anybody help me please

Nabijon
  • 821
  • 2
  • 13
  • 17

2 Answers2

19

The MPEG2 transport stream clocks (PCR, PTS, DTS) all have units of 1/90000 second. The PTS and DTS have three marker bits which you need to skip over. The pattern is always (from most to least significant bit) 3 bits, marker, 15 bits, marker, 15 bits, marker. The markers must be equal to 1. In C, removing the markers would work like this:

uint64_t v; // this is a 64bit integer, lowest 36 bits contain a timestamp with markers
uint64_t pts = 0;
pts |= (v >> 3) & (0x0007 << 30); // top 3 bits, shifted left by 3, other bits zeroed out
pts |= (v >> 2) & (0x7fff << 15); // middle 15 bits
pts |= (v >> 1) & (0x7fff <<  0); // bottom 15 bits
// pts now has correct timestamp without markers in lowest 33 bits

They also have an extension field of 9bits, forming a 42bit integer in which the extension is the least significant bits. The units for the base+extension are 1/27000000 second. Many implementations leave the extension as all zeros.

Alex I
  • 19,689
  • 9
  • 86
  • 158
  • Hi Alex I, Long shot here; do you know why the data is stored in this way? I've looked around and I haven't been able to find an answer. – jpihl Oct 19 '17 at 07:41
  • 1
    @jpihl I suspect the markers are there for one of two reasons: (1) to catch all-zero timestamps as being invalid, and (2) to catch bitstreams that are being read or decoded a bit at a time as being invalid when there is a bit offset. The units of 90000 are chosen so that both 30 fps and 29.97 fps are exact fractions. – Alex I Oct 19 '17 at 21:27
  • I see, those are both good points, thank you very much! To me it just seemed like it made the spec more complicated for no good reason. – jpihl Oct 20 '17 at 05:39
  • Actually extension to 27MHz has **PCR** only. **PTS** and **DTS** have units in 90KHz only. *NOTE:* only [0,299] values used from 9bit of extension (not full range [0,511]). – SergA Jan 09 '20 at 10:13
8

24hours/day * 60min/hr * 60secs/min *90k/sec (clock) = 7962624000, which needs 33 bits to be represented; You can extract your time from the clock using this info;

RGovindan
  • 81
  • 1
  • 1
  • Nice remark. I think the "k" is for 1e3 (not "K"). so 7776000000 still 33bits though. – code7amza Jun 21 '13 at 03:03
  • does it mean I can get absolute time of day at encoder side from PTS? Just using 00:00:00 as the base? – wick Feb 28 '14 at 12:38
  • 3
    @wick No, unfortunately it doesn't mean that. PTS starts at an arbitrary value, it's not specified in the standard. Most programs/devices that produce transport streams start at 0 for the beginning of each stream. They *could* start at the time of day expressed in PTS, but in practice none do that. – Alex I May 25 '14 at 05:22
  • PTS could be combined with PCR to get actual clock at the encoder side, though it is not guaranteed in any way to have any relation to the wall clock :). – weaknespase Jul 15 '17 at 16:52