Propagate original NTP timestamp of RTP packets

[aler9]

Describe the feature

1. implement Allow to get the NTP timestamp of incoming packets, in both server and client gortsplib#159
2. use original NTP timestamp timestamp inside the server, replacing it only in case it's missing
3. test what happens when there's a big discrepancy between a reader's NTP and a camera's NTP

[leidix]

Any update on this?
I would love to see this feature for downstream analysis and syncing streams from multiple senders.
Cheers!

[dragulesq]

I definitely need this for the my current project. I would like to use these timestamps with recordings of the stream later to extract still frames.

[aler9]

Current situation regarding ingestion of absolute timestamp:

• HLS sources provide absolute timestamp through EXT-X-PROGRAM-DATE-TIME, but this value is currently unused by the server
• RTMP sources / clients don't provide absolute timestamp
• RTSP sources / clients provide absolute timestamp through RTCP sender reports, but there's a time gap between the start of the stream and the reception of the first RTCP sender report in which absolute timestamp is not available
• WebRTC clients behaves in the same exact way as RTSP sources / clients since they both use RTCP and RTP
• SRT sources / clients may provide absolute timestamp through an MPEG-TS extension
• UDP / MPEG-TS sources behaves in the same way as SRT sources

Therefore, the absolute timestamp of incoming streams of all protocols is currently assumed to be the current timestamp of the server.

This timestamp is propagated by the server to readers through all supported means (EXT-X-PROGRAM-DATE-TIME and RTCP sender reports).

[0xAl3xH]

RTSP sources / clients provide absolute timestamp through RTCP sender reports, but there's a time gap between the start of the stream and the reception of the first RTCP sender report in which absolute timestamp is not available
...
Therefore, the absolute timestamp of incoming streams of all protocols is currently assumed to be the current timestamp of the server.

Just to double check - this means the #EXT-X-PROGRAM-DATE-TIME I see in my .m3u8 is actually just the time that segment is created on the mediamtx server and NOT propagated from the wall clock time of the recording from source?

[wizenink]

Bumping this. We currently have an ancient version of rtsp-simple-server because it did not rewrite RTCP NTP times. Is there any new info on this? does mediamtx propagate original ntp timestamps?

[perchess]

Bumping this. We currently have an ancient version of rtsp-simple-server because it did not rewrite RTCP NTP times. Is there any new info on this? does mediamtx propagate original ntp timestamps?

Based on my tests, MediaMTX still rewrites RTCP NTP timestamps. However, if an external RTSP server is connected as a "proxy," MediaMTX does not rewrite the timestamps in that case.

@aler9 Would it be possible to add a configuration parameter to disable RTCP NTP timestamp overwriting?

[georgiuk]

@aler9 Would it be possible to add a configuration parameter to disable RTCP NTP timestamp overwriting?

It would be nice to have for sure.