New jitter buffer experiment.

webrtc/modules/video_coding/frame_buffer2.cc

Index: webrtc/modules/video_coding/frame_buffer2.cc
diff --git a/webrtc/modules/video_coding/frame_buffer2.cc b/webrtc/modules/video_coding/frame_buffer2.cc
index daac7d5c2b2d691e84a7c0a83e93ec3b20e3823f..e02e5b6071c14bcb72567d0a43600ae6959b68c3 100644
--- a/webrtc/modules/video_coding/frame_buffer2.cc
+++ b/webrtc/modules/video_coding/frame_buffer2.cc
@@ -28,7 +28,7 @@ namespace {
 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,
@@ -114,7 +114,7 @@ FrameBuffer::ReturnReason FrameBuffer::NextFrame(
   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,