commit 8c4fe16e4cba63b294747e37b704047b90f69212
author Ilya Nikolaevskiy <ilnik@webrtc.org> Tue Feb 27 15:49:47 2018 +0100
committer Commit Bot <commit-bot@chromium.org> Tue Feb 27 16:31:29 2018 +0000
tree 3e3d1e62d8e77d15d5b5244ffdf0305d680e4830
parent 99a2c5dcb677d8833cba9256b4e31ce8e604b75e

Make Frame buffer not drop frames unnecessary

Now VCMTiming::MaxWaitingTime will not clip negative values. Thus frame
buffer will be able to distinguish between late frames and when waiting
cycle was simply interrupted by a new inserted frame right before the
waiting timer would expire.

Bug: webrtc:8917
Change-Id: I6b253f459fcb3a346064a103cc92ee332b074e1b
Reviewed-on: https://webrtc-review.googlesource.com/57741
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22210}

modules/video_coding/frame_buffer2.cc

diff --git a/modules/video_coding/frame_buffer2.cc b/modules/video_coding/frame_buffer2.cc
index db09e76..dbd222f 100644
--- a/modules/video_coding/frame_buffer2.cc
+++ b/modules/video_coding/frame_buffer2.cc
@@ -34,6 +34,10 @@
 // Max number of decoded frame info that will be saved.
 constexpr int kMaxFramesHistory = 50;
 
+// The time it's allowed for a frame to be late to its rendering prediction and
+// still be rendered.
+constexpr int kMaxAllowedFrameDalayMs = 5;
+
 constexpr int64_t kLogNonDecodedIntervalMs = 5000;
 }  // namespace
 
@@ -119,7 +123,9 @@
         // This will cause the frame buffer to prefer high framerate rather
         // than high resolution in the case of the decoder not decoding fast
         // enough and the stream has multiple spatial and temporal layers.
-        if (wait_ms == 0)
+        // For multiple temporal layers it may cause non-base layer frames to be
+        // skipped if they are late.
+        if (wait_ms < -kMaxAllowedFrameDalayMs)
           continue;
 
         break;