[Q] Extract SRT source (or other input) time stamps and correlate to nearest PTS?

[jheliker]

Hello -

Thank you for the excellent toolset.

I am looking for a way to extract SRT source time stamps and correlate them to the nearest PTS for a given service.

I see that we can use the pcrextract plugin to log PTS information, however, I don't see a way to correlate this to input time stamps.

The only relevant area I've found in the documentation is the SRT input --timestamp-priority option, which appears to allow us to prioritize SRT source time stamps over RTP or the software's (tsp), however, I don't see a way to log these input time stamps.

Is this possible?

[lelegard]

Hi @jheliker

Good question. The input plugins of tsp extract an input timestamp for each TS packet. This could be a RTP, SRT, M2TS, PCAP, etc. value. As last resort, if the input plugin cannot provide any timestamp, the tsp framework provides the system time when the input plugin return.

For consistency, all input timestamp values are converted in PCR units.

The type of timestamp is also saved: RTP, SRT, M2TS, PCAP, etc.

When several instances of tsp are piped with file, fork, merge plugins, the original timestamp of the first receiver is propagated from tsp to tsp if the option --format duck is used in the file, fork, merge plugins.

So, the information is here but there is no way to correlate it with PCR or other timestamps inside the TS.

Therefore, I just added an option --input-timestamp to plugin pcrextract. For each timestamp, PCR, PTS, DTS, it adds the input timestamp of the corresponding TS packet. Also reported (in the CSV output): input timestamp type and difference between the timestamp from the stream (PCR, PTS, DTS) and the input timestamp (converted first if the timestamp to compare is a PTS or DTS).

Use your favorite Excel to process the CSV output.

You have to rebuild from the repo to get this option.

[jheliker]

Hi @lelegard

Thank you for the quick response and solution, I'm excited to try out what you've added.

One question for my understanding - why is it that some plugins, for example RIST input, do not have any option like the --timestamp-priority? Does it not carry time stamps the way that SRT does?

Much appreciated!

[lelegard]

The option --timestamp-priority makes sense only when you have several possible sources of timestamps from incoming packets and there is no obvious or general or reliable way to choose the same one in all situations.

In the case of RIST, the librist API does not document any incoming timestamp. So, there is no other choice than a system timestamp.

I just had a look at the librist headers. There is one undocumented field named ts_ntp in the RIST data block which may be some sort of timestamps. However, we don't know its usage or unit. I will have a look at librist internal source code to see if we can get something about it.

[lelegard]

After reading the librist source code, ts_ntp is the sender's time stamp in NTP format. So, I now use it as input time stamp, unless --ignore-rist-timestamp is specified.

[jheliker]

Hi @lelegard

Thank you so much for the quick follow up and expertise. It is much appreciated!

I know you mentioned needing to build from source for these changes. When do you anticipate the next pre-built release becoming available?

[lelegard]

Daily builds are produced every night (European perspective) for Windows and Ubuntu 22.04 LTS.
Available here: https://tsduck.io/download/prerelease/
The next one should be 3.37-3654.

For other platforms, the rebuild instructions are here: https://tsduck.io/doxy/building.html

Any other requirement?

[jheliker]

That is very helpful, thank you @lelegard.

[jheliker]

@lelegard Can you please confirm what unit of measure these timestamps are reported in? I assumed 90 kHz ticks, but want to confirm. Thank you!!

[lelegard]

Each time stamp is reported in its "natural unit", 90 kHz for PTS and DTS, 27 MHz for PCR.

The "input timestamp" are always reported in PCR units, ie. 27 MHz.

In practice, the input timestamp can come from various types of clocks, RTP, SRT, NIC hardware clock, system clock, pcap timestamp, etc. So, for consistency, it is always converted in the same unit as the TS Program Clock Reference.

[jheliker]

Hi @lelegard,

After trying to use this with some "real" SRT stream data and not having success, I've been researching the SRT protocol itself.

According to this: https://haivision.github.io/srt-rfc/draft-sharabayko-srt.html#section-3-6.4.1 it would appear that the timestamps carried in SRT packets are microseconds relative to the time that the SRT connection was established.

Unless there is a way of keeping track of precisely when the connection is established perhaps during the handshake, it seems this sort of correlation or attempt to correlate to the sender/encoder's time is not possible with the SRT protocol?

In contrast, it does seem to me that the ts_ntp field you found for RIST carries the actual sender/encoder's time.

Would love your thoughts... I very much appreciate the assistance.

[lelegard]

There is no "universal time" in all these protocols. In a TS, there is no "epoch" for PCR. Inside a MPTS, distinct services typically use completely independent PCR, especially if the various A/V come from distinct encoders.

SRT is a transport protocol. Even though most people use it to carry TS, there is no relationship between the transport clock and the various clocks inside the transported data. Especially if the TS contains multiple services with distinct PCR references.

So, the best you can do is, at some point, establish an initial correlation between "input timestamp value X", "service 1 PCR value Y", "service 2 PCR value Z". Then, you can monitor the variations in the differences between these values.