- From: ilnik via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Nov 2018 10:04:21 +0000
- To: public-webrtc-logs@w3.org
Do you use WebRTC in-chrome, or as a standalone library. In the former case i think you can already access each frame NTP timestamp, which is the capture time of the frame in the receiver clock, Thus, you can detect jumps in two consecutive frame timestamps and see the difference. This timestamp is estimated after we have an RTT estimate, so you either need receiver to send some video back, or enable RTRR for receiver-only RTT estimation, which can be done with a hack in SDP string. Alternatively, you can access RTP timestamps, these are generated by webrtc by taking local capture time in milliseconds and multiplying it by 90. So if frames are exactly 33ms apart, you will see 33*90=2970 differences between RTP tiemstamps. Here: https://cs.chromium.org/chromium/src/third_party/webrtc/api/video/video_frame.h?sq=package:chromium&dr=CSs&l=88 timestamp() is RTP tiemstamp ntp_timestamps() is the capture time. It will be -1 if RTT estimate is unavailable or not enough RTCP SR packets were received yet. If you are working in-chrome, then i am not really sure. -- GitHub Notification of comment by ilyanikolaevskiy Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/229#issuecomment-436197750 using your GitHub account
Received on Tuesday, 6 November 2018 10:04:23 UTC