-1

In program stream, I got first pes packet with PTS value "4295626096" and dts value 648000 and next packet pts value is much lesser than first packet. Some pes packet values are as follows: Pes packet1 : pts 4295626096 dts 648000. Pes packet2 : pts 651600. Pes packet3 : pts 655200. Pes packet4 : pts 4295636896 dts 658800. Pes packet5 : pts 662400. Pes packet6 : pts 666000. Pes packet7 : pts 4295647696 dts 669600. Pes packet8 : pts 673200. Pes packet9 : pts 676800. Pes packet10:pts 429565896 dts 680400. and next packets pts are 684000, 687600, 702000, 694800, 698400 ...... seems correct now.

When i googled about this, I found that if 33 bit value of SCR/PTS/DTS is 1, It is a case of overflow, but i didn't find the same in standard.

Can anyone explain the scenario when overflow case occur and how to handle overflow case(to get the correct time-stamp) to get the proper PTS value.

Vivek
  • 1
  • 1

1 Answers1

0

Whoever said the 33rd bit was was overflow is incorrect. What you need to do is convert to a monotonic timestamp by accumulating the differences between the current timestamp and previous timestamp

In C++:

int64_t subtract_timestamp(int64_t previous, int64_t current)
{
    int64_t diff = current - previous;

    if ((0x1FFFFFFFF/2) < -diff) {
        return (0x1FFFFFFFF - previous) + current;
    }

    return diff;
}

int64_t previous = 0;
int64_t my_timestamp = 0;

void my_function(int64_t dts) {
    my_timestamp += subtract_timestamp(previous, dts);
    previous = dts;
}
szatmary
  • 29,969
  • 8
  • 44
  • 57
  • Thanks szatmary. I have two doubts in your code. 1. what do you want to check by dividing possible pts/dts max_value 0x1FFFFFFFF by 2 [ if ((0x1FFFFFFFF/2) < -diff)] ? 2. What is the timestamp in [ int64_t diff = timestamp - current;] code segment. – Vivek May 31 '17 at 06:52
  • The edge case you are missing is non monotonic input. If previous is 2 and current is 1, it's not an overflow it's a nonmonotonic time stamp. This code would return -1 in that case, allowing you to handle the error. what we are checking is that when it went from X to Y did it cover more than 50% of the number line. If so, it's an error, not a rollover (this is standard practice for time stamps) – szatmary May 31 '17 at 13:47
  • Sorry for the typo. (I wrote this when on a commuter train) fixed. – szatmary May 31 '17 at 13:53
  • Basically, what is the shortest path from current to previous, to go back the way I came (negative difference) or continue the overflow? That's what this calculates. – szatmary May 31 '17 at 14:01