Index: webrtc/video/vie_encoder.cc |
diff --git a/webrtc/video/vie_encoder.cc b/webrtc/video/vie_encoder.cc |
index b56bbf5153852af7c67e70fff1395ef52677639d..9fd977941171c2cc02b3d287d9c8c837d9653c7b 100644 |
--- a/webrtc/video/vie_encoder.cc |
+++ b/webrtc/video/vie_encoder.cc |
@@ -564,7 +564,13 @@ void ViEEncoder::OnFrame(const VideoFrame& video_frame) { |
VideoFrame incoming_frame = video_frame; |
// Local time in webrtc time base. |
- int64_t current_time_ms = clock_->TimeInMilliseconds(); |
+ int64_t current_time_us = clock_->TimeInMicroseconds(); |
+ int64_t current_time_ms = current_time_us / rtc::kNumMicrosecsPerMillisec; |
+ // If the frame is not from the capturer but from decoder, render time may |
+ // be set to the future. To avoid irregularities in statistics, where frame |
+ // is captured after being encoded, we should reset capture time here. |
+ if (incoming_frame.timestamp_us() > current_time_us) |
nisse-webrtc
2017/06/02 12:04:55
I don't quite understand the problem here, and I'd
ilnik
2017/06/02 13:02:21
Problem is that timestamps are sent over network a
nisse-webrtc
2017/06/08 06:58:36
I think I'm missing some context here, can you hel
ilnik
2017/06/08 07:26:00
It happens in PeerConnectionIntegrationTest.CanSen
nisse-webrtc
2017/06/08 07:38:36
Ok, I see. Could you clarify the comment a bit? I
ilnik
2017/06/08 08:01:43
I clarified the comment.
About the broad refacto
|
+ incoming_frame.set_timestamp_us(current_time_us); |
// Capture time may come from clock with an offset and drift from clock_. |
int64_t capture_ntp_time_ms; |