mediamtx icon indicating copy to clipboard operation
mediamtx copied to clipboard

Propagate original NTP timestamp of RTP packets

Open aler9 opened this issue 2 years ago • 4 comments

Describe the feature

  1. implement https://github.com/aler9/gortsplib/issues/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

aler9 avatar Dec 12 '22 18:12 aler9

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

leidix avatar Jun 26 '23 15:06 leidix

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.

dragulesq avatar Jul 19 '23 00:07 dragulesq

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).

aler9 avatar Jul 19 '23 10:07 aler9

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?

0xAl3xH avatar May 27 '24 21:05 0xAl3xH