Bug 1515205 - Always set frame timestamps in VideoStreamEncoder::OnFrame; r=drno
authorDan Minor <dminor@mozilla.com>
Wed, 23 Jan 2019 20:48:20 +0000
changeset 515200 a77e9c7eabb535d9d114ae4f1733f1d954132f14
parent 515199 5f1830b621aa67dedf3a9da4e8311b732a0bde97
child 515201 b0b61b6a4014ee5d9b8257b660cde6a55df66522
push id1953
push userffxbld-merge
push dateMon, 11 Mar 2019 12:10:20 +0000
treeherdermozilla-release@9c35dcbaa899 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersdrno
bugs1515205
milestone66.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1515205 - Always set frame timestamps in VideoStreamEncoder::OnFrame; r=drno In the past we relied upon ViEEncoder::OnFrame to set the render time for frames. With the branch 64 update, this code moved to VideoStreamEncoder::OnFrame, and only sets the timestamp if it is greater than the current time. This results in broken rtp timestamp estimates in the rtcp sender report, which causes problems for Meet and possibly other services that rewrite rtp timestamps based upon the sender report. This patch makes VideoStreamEncoder::OnFrame always set the timestamp. In a follow on bug, we'll move this behaviour to VideoConduit so we don't have to maintain a local modification of the upstream code. Differential Revision: https://phabricator.services.mozilla.com/D17413
media/webrtc/trunk/webrtc/video/video_stream_encoder.cc
--- a/media/webrtc/trunk/webrtc/video/video_stream_encoder.cc
+++ b/media/webrtc/trunk/webrtc/video/video_stream_encoder.cc
@@ -673,18 +673,21 @@ void VideoStreamEncoder::OnFrame(const V
 
   // Local time in webrtc time base.
   int64_t current_time_us = clock_->TimeInMicroseconds();
   int64_t current_time_ms = current_time_us / rtc::kNumMicrosecsPerMillisec;
   // In some cases, e.g., when the frame from decoder is fed to encoder,
   // the timestamp may be set to the future. As the encoding pipeline assumes
   // 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);
+
+  // Mozilla: Because we don't set timestamps earlier, we need to always set
+  // them here. We should do this in VideoConduit, see Bug 1522238.
+  //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 {