Bug Fix: WebRTC Receiver Timestamp Jump Detection

RTCVideoEncoder does not propagate RTP timestamps properly for encoded video frames, and as such whenever switching between simulcast layers there's a large timestamp gap that causes the incoming stream to freeze (timestamps look like they're either too far ahead or too far behind the previous frame).

Ideally RTCVideoEncoder would propagate these timestamps, but even so, when there's a large timestamp gap it would seem reasonable that the receiver resets quickly and consider this to be a new stream.

This CL detects the large jump for timestamps, if that happens, we reset the time extrapolator, which is the class for convertion from RTP timestamp to clock time.

BUG=chromium:705679

Review-Url: https://codereview.webrtc.org/2776813002
Cr-Commit-Position: refs/heads/master@{#17770}

webrtc/system_wrappers/source/timestamp_extrapolator.cc

@@ -85,14 +85,6 @@ TimestampExtrapolator::Update(int64_t tMs, uint32_t ts90khz)
     int64_t unwrapped_ts90khz = static_cast<int64_t>(ts90khz) +
         _wrapArounds * ((static_cast<int64_t>(1) << 32) - 1);
 
-    if (_prevUnwrappedTimestamp >= 0 &&
-        unwrapped_ts90khz < _prevUnwrappedTimestamp)
-    {
-        // Drop reordered frames.
-        _rwLock->ReleaseLockExclusive();
-        return;
-    }
-
     if (_firstAfterReset)
     {
         // Make an initial guess of the offset,
@@ -114,6 +106,15 @@ TimestampExtrapolator::Update(int64_t tMs, uint32_t ts90khz)
         // the offset uncertainty. Don't do this during startup.
         _pP[1][1] = _pP11;
     }
+
+    if (_prevUnwrappedTimestamp >= 0 &&
+        unwrapped_ts90khz < _prevUnwrappedTimestamp)
+    {
+        // Drop reordered frames.
+        _rwLock->ReleaseLockExclusive();
+        return;
+    }
+
     //T = [t(k) 1]';
     //that = T'*w;
     //K = P*T/(lambda + T'*P*T);