New jitter buffer experiment.

webrtc/modules/video_coding/frame_buffer2.cc

 /*
  *  Copyright (c) 2016 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 10 matching lines @@
 #include "webrtc/system_wrappers/include/clock.h"
 
 namespace webrtc {
 namespace video_coding {
 
 namespace {
 // Max number of frames the buffer will hold.
 constexpr int kMaxFramesBuffered = 600;
 
 // Max number of decoded frame info that will be saved.
-constexpr int kMaxFramesHistory = 20;
+constexpr int kMaxFramesHistory = 50;
 }  // namespace
 
 FrameBuffer::FrameBuffer(Clock* clock,
                          VCMJitterEstimator* jitter_estimator,
                          VCMTiming* timing)
     : clock_(clock),
       new_countinuous_frame_event_(false, false),
       jitter_estimator_(jitter_estimator),
       timing_(timing),
       inter_frame_delay_(clock_->TimeInMilliseconds()),
@@ skipping 65 matching lines @@
     }  // rtc::Critscope lock(&crit_);
 
     wait_ms = std::min<int64_t>(wait_ms, latest_return_time - now_ms);
     wait_ms = std::max<int64_t>(wait_ms, 0);
   } while (new_countinuous_frame_event_.Wait(wait_ms));
 
   rtc::CritScope lock(&crit_);
   if (next_frame_it != frames_.end()) {
     std::unique_ptr<FrameObject> frame = std::move(next_frame_it->second.frame);
     int64_t received_time = frame->ReceivedTime();
-    uint32_t timestamp = frame->Timestamp();
+    uint32_t timestamp = frame->timestamp;

[nisse-webrtc, 2016/11/08 11:56:30]

Would be better with an accessor method also for timestamp. And unit is unclear,
other places use a unit-suffix, like timestamp_us() or timestamp_ms().

[philipel, 2016/11/08 12:28:39]

I agree on the accessor method, but just "timestamp" is established (at least in
the video team) as the timestamp of a frame. Also, the unit may vary between
codecs.

[danilchap, 2016/11/08 12:37:21]

may be rename it to rtp_timestamp

[nisse-webrtc, 2016/11/08 12:58:12]

Ouch. Does it really have to be a codec-specific unit?

[philipel, 2016/11/08 13:35:51]

Sounds good, WDYT stefan@?

[philipel, 2016/11/08 13:35:51]

Well, for VP8/VP9/H264 the timestamp is a 90 kHz clock, but that is not true for
all codecs.

[nisse-webrtc, 2016/11/11 07:53:12]

It makes some sense to me, if that's what it is used for. And then it's unlikely
to ever be anything but units of the 90 kHz clock?

But I'm still trying to understand the codec dependency. The RTP profile for any
particular codec specifies the unit of rtp timestamps on the wire, which is 90
kHz for all codecs we care about. Right? But is there anything outside of the
RTP code that really needs 90kHz? E.g., are these timestamps somehow used in
combination with pts/dts timestamps in the bitstream?

For quic, I think it's unlikely that we'll have any 90 kHz timestamps on the
wire, so that's one motivation to try to move away from rtp-specific units here.
I have been trying to push for us units everywhere in the video pipeline; that's
sufficient accuracy that it can be converted to 90kHz and back when needed,
without worrying about the small rounding errors.

 
     int64_t frame_delay;
     if (inter_frame_delay_.CalculateDelay(timestamp, &frame_delay,
                                           received_time)) {
       jitter_estimator_->UpdateEstimate(frame_delay, frame->size());
     }
     float rtt_mult = protection_mode_ == kProtectionNackFEC ? 0.0 : 1.0;
     timing_->SetJitterDelay(jitter_estimator_->GetJitterEstimate(rtt_mult));
     timing_->UpdateCurrentDelay(frame->RenderTime(),
                                 clock_->TimeInMilliseconds());
@@ skipping 220 matching lines @@
   }
 
   RTC_DCHECK_LE(info->second.num_missing_continuous,
                 info->second.num_missing_decodable);
 
   return true;
 }
 
 }  // namespace video_coding
 }  // namespace webrtc