Handle PTS rollovers

[slifty]

Task

Description

MPEG PTS and DTS have a limit, and when that limit is reached they roll over.

I'm not certain if the rollover is part of the MPEGTS standard (e.g. it will always roll over at 2^33) or if it is up to the encoding agent to determine when to initiate a rollover. Handling rollovers is non-trivial for that reason, so this issue will require a bit of R&D before implementation.

The solution needs to work for stream and file based videos (e.g. a file with 2 weeks of video would have a rollover as well). This means that the rollover should be in terms of the origin that is passed to the video ingestion appliance (as opposed to some kind of logic like if PTS went down, use the current time as origin).

[slifty]

Some relevant threads related to timestamp rollover as I find them:

• https://libav-user.ffmpeg.narkive.com/d7lbqHGA/33-bit-rollover-in-mpeg

• https://stackoverflow.com/a/27534692/159522

First, transport streams were originally intended for very long broadcasts (days or weeks. Think television stations). TS uses 33 bits to store 90kHz ticks. This makes timesamp rollovers very common (about once a day). Because the timestamp rolls over so frequently, It is generally not a good idea to rely on the time stamps as anything other than an arbitrary tick on a ever moving clock with a start time at an unknown point in the past. Think of an analog clock, and remove all markings. Without the orientation, you can not use it to tell time. But you can still use it to measure time. In other words the timestamps only have meaning relative to other timestamps in the stream. They do not exist for human convenience. They exist so the decoder can do its job.

• A similar issue in a project that works with TS PTS/DTS adjustment produces negative PTS/DTS values video-dev/hls.js#1796

[slifty]

It looks like the answer is to detect discontinuity and add 2^33 / 90000 ms to the "origin time" whenever a rollover occurs.