Re: Defining "timeline offset" for various formats

From: Brendan Long <B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>>
Date: Wednesday, May 21, 2014 at 2:42 PM
To: Aaron Colwell <acolwell@google.com<mailto:acolwell@google.com>>
Cc: "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: RE: Defining "timeline offset" for various formats
Resent-From: "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Resent-Date: Wednesday, May 21, 2014 at 2:43 PM


On Tue, May 20, 2014 at 1:57 PM, Brendan Long <B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>> wrote:
For normal MPEG-TS, there isn't a descriptor that maps to this, so I'd say leave it at NaN.

Interesting. I didn't realize that MPEG-TS didn't map timestamps in the transport to any sort of wall clock time.
Maybe I'm just confused about what this is supposed to represent, but MPEG-TS doesn't store information like an absolute timestamp for the start of the file (ex: May 20th 2014 at 5:25 pm).

We do have the PCR and PTS, so we could do something like picking the first PTS, but they're meant for synchronization, and from my quick look at the standard, it doesn't seem to require that they have any particular values, as long as they're consistent.

2.1.42 Program Clock Reference; PCR (system): A time stamp in the Transport Stream from which decoder timing is derived.

2.1.39 presentation time-stamp; PTS (system): A field that may be present in a PES packet header that indicates the time that a presentation unit is presented in the system target decoder.

Both of these are essentially counters of clocks at 27 and 19 MHz, respectively  (if my memory hasn’t failed me)