Implement timing frames.

webrtc/video/vie_encoder.cc

Index: webrtc/video/vie_encoder.cc
diff --git a/webrtc/video/vie_encoder.cc b/webrtc/video/vie_encoder.cc
index 63b1c80fefbe9b0f0f8afaf95a83dd0f140a3540..5d75d907e9e63e0a09fe7f930ecadb28cffb5713 100644
--- a/webrtc/video/vie_encoder.cc
+++ b/webrtc/video/vie_encoder.cc
@@ -622,7 +622,14 @@ 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;
+  // In some cases, e.g. then the frame from decoder is fed to encoder,

[holmer, 2017/06/19 07:48:26]

"e.g. when"?

[nisse-webrtc, 2017/06/19 08:08:39]

To be *really* picky, it should be ", e.g., when".

[ilnik, 2017/06/19 08:41:51]

Done.

[ilnik, 2017/06/19 08:41:51]

Done.

+  // the timestamp may be set to the future. As the encoding pipeline assumes

[holmer, 2017/06/19 07:48:26]

I don't understand why this would be the case. Can you explain why frames passed
from the decoder to the encoder may have timestamps in the future?

[nisse-webrtc, 2017/06/19 08:08:39]

Because the decoder doesn't even try to attach the original capture time (which
would lie in the past). Instead, it attaches a timestamp for a suitable render
time, which by intention is in the future.

At least that's my understanding. I would prefer if the decoder estimated the
(past) capture time as well as it can, and playout delay for rendering was added
somewhere else, closer to actual rendering. But that's a refactoring for a
different cl.

[ilnik, 2017/06/19 08:41:51]

Yes, that's what happens.

[holmer, 2017/06/19 12:17:47]

Acknowledged, and I agree with your preferences. :)

+  // capture time to be less than present time, we should reset the capture
+  // timestamps here. Otherwise there may be issues with RTP send stream.
+  if (incoming_frame.timestamp_us() > current_time_us)
+    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;