Drop back to back frames in VideoFrameResolutionAdapter::MaybeDropFrame.

content/renderer/media/video_track_adapter.cc

Index: content/renderer/media/video_track_adapter.cc
diff --git a/content/renderer/media/video_track_adapter.cc b/content/renderer/media/video_track_adapter.cc
index ebb47ba9f86b3f0fd4c3d70329706f435ddeff80..a81bec03750d386a27385dcfa56b9272ded6197b 100644
--- a/content/renderer/media/video_track_adapter.cc
+++ b/content/renderer/media/video_track_adapter.cc
@@ -24,6 +24,10 @@ namespace {
 const float kFirstFrameTimeoutInFrameIntervals = 100.0f;
 const float kNormalFrameTimeoutInFrameIntervals = 25.0f;
 
+// Min delta time between two frames allowed without being dropped if a max
+// frame rate is specified.
+const int kMinTimeInMsBetweenFrames = 5;
+
 // Empty method used for keeping a reference to the original media::VideoFrame
 // in VideoFrameResolutionAdapter::DeliverFrame if cropping is needed.
 // The reference to |frame| is kept in the closure that calls this method.
@@ -225,11 +229,20 @@ bool VideoTrackAdapter::VideoFrameResolutionAdapter::MaybeDropFrame(
     return false;
 
   base::TimeDelta delta = frame->timestamp() - last_time_stamp_;
+  if (delta.InMilliseconds() < kMinTimeInMsBetweenFrames) {
+    // We have seen video frames being delivered from camera devices back to
+    // back. The simple AR filter for frame rate calculation is too short to
+    // handle that. Frames rendered back to back are not visible to the eye
+    // anyway so therefore instead dropped.

[tommi (sloooow) - chröme, 2014/08/28 09:01:39]

To be fair, when this happens, the frames were very likely not actually captured
at the interval that the timestamps suggest (unless we're trying to render
something in realtime from an ultra-speed video camera).
I'd rather like a todo here for handling/correcting the situation where the
timestamps are bad.  Given that the timestamps have been proven to be unreliable
in some cases, it would be good to not actually have to rely on them :)

I also don't think we should be making assumptions about the relevance of what's
visible to the naked eye since this code should be generic and not aware of
whether or not the track is going to ultimately be rendered at the same speed
it's being captured.  (think e.g. of the above cameras, recording, later
playback at a fraction of the capture fps).

+    DVLOG(3) << "Drop frame since delta time since previous frame is "
+             << delta.InMilliseconds();

[mcasas, 2014/08/28 08:26:40]

nit: add 
<< "ms";
after delta.InMilliseconds()

+    return true;
+  }
   last_time_stamp_ = frame->timestamp();
-  if (delta.ToInternalValue() == 0 || delta == last_time_stamp_)
+  if (delta == last_time_stamp_) // First received frame.
     return false;
-  // Calculate the moving average frame rate. Use a simple filter with 0.1
-  // weight of the current sample.
+  // Calculate the frame rate using a simple AR filter.
+  // Use a simple filter with 0.1 weight of the current sample.
   frame_rate_ = 100 / delta.InMillisecondsF() + 0.9 * frame_rate_;
 
   // Prefer to not drop frames.