Implement timing frames.

webrtc/video/vie_encoder.cc

 /*
  *  Copyright (c) 2012 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
@@ skipping 604 matching lines @@
 
   stats_proxy_->SetAdaptationStats(GetActiveCounts(kCpu),
                                    GetActiveCounts(kQuality));
 }
 
 void ViEEncoder::OnFrame(const VideoFrame& video_frame) {
   RTC_DCHECK_RUNS_SERIALIZED(&incoming_frame_race_checker_);
   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;
   if (video_frame.ntp_time_ms() > 0) {
     capture_ntp_time_ms = video_frame.ntp_time_ms();
   } else if (video_frame.render_time_ms() != 0) {
     capture_ntp_time_ms = video_frame.render_time_ms() + delta_ntp_internal_ms_;
   } else {
     capture_ntp_time_ms = current_time_ms + delta_ntp_internal_ms_;
   }
@@ skipping 510 matching lines @@
 std::string ViEEncoder::AdaptCounter::ToString(
     const std::vector<int>& counters) const {
   std::stringstream ss;
   for (size_t reason = 0; reason < kScaleReasonSize; ++reason) {
     ss << (reason ? " cpu" : "quality") << ":" << counters[reason];
   }
   return ss.str();
 }
 
 }  // namespace webrtc