Cast: Using a min filter to compute time offset

media/cast/video_receiver/video_receiver.cc

Index: media/cast/video_receiver/video_receiver.cc
diff --git a/media/cast/video_receiver/video_receiver.cc b/media/cast/video_receiver/video_receiver.cc
index 799da9a2d48b364b3bbf088c2a19d0035a299062..113845c69600a570229de991a0c81e2df898e97f 100644
--- a/media/cast/video_receiver/video_receiver.cc
+++ b/media/cast/video_receiver/video_receiver.cc
@@ -107,6 +107,7 @@ VideoReceiver::VideoReceiver(scoped_refptr<CastEnvironment> cast_environment,
                     incoming_payload_callback_.get()),
       rtp_video_receiver_statistics_(
           new LocalRtpReceiverStatistics(&rtp_receiver_)),
+      time_offset_counter_(0),
       decryptor_(),
       time_incoming_packet_updated_(false),
       incoming_rtp_timestamp_(0),
@@ -365,6 +366,7 @@ base::TimeTicks VideoReceiver::GetRenderTime(base::TimeTicks now,
       return now;
     }
     time_offset_ = time_incoming_packet_ - rtp_timestamp_in_ticks;
+    ++time_offset_counter_;
   } else if (time_incoming_packet_updated_) {
     if (rtcp_->RtpTimestampInSenderTime(kVideoFrequency,
                                         incoming_rtp_timestamp_,
@@ -372,8 +374,9 @@ base::TimeTicks VideoReceiver::GetRenderTime(base::TimeTicks now,
       // Time to update the time_offset.
       base::TimeDelta time_offset =
           time_incoming_packet_ - rtp_timestamp_in_ticks;
-      time_offset_ = ((kTimeOffsetFilter - 1) * time_offset_ + time_offset) /
-                     kTimeOffsetFilter;
+      if (time_offset_counter_  < 10 && time_offset < time_offset_)
+        time_offset_ = time_offset;
+      ++time_offset_counter_;

[hguihot1, 2014/03/03 23:20:59]

The previous filter was basically doing:

time_offset_ = ((7 * time_offset_) + time_offset) / 8;

Could the issue have been that when you only have for example 2 samples this was
basically doing:

time_offset_ = ((7 * first_time_offset_sample) + second_time_offset_sample) / 8;

In other words, the first sample was counting for 7/8 of the new average, vs.
only 1/8 for the second sample. In general, first samples were counting for
more.

[mikhal1, 2014/03/03 23:33:23]

That is indeed part of the problem, which can be described as follows:
1. The initial value can be very off if sender starts before receiver.
2. Given the slow adaptation of this filter, conversion from a bad value took a
very long time.
3. In an unstable wi-fi setting, these values may fluctuate significantly. We
are not interested in these fluctuations, but in finding the offset, which will
be best estimated at the best network setting, i.e. minimum value over time. 
On 2014/03/03 23:20:59, hguihot1 wrote:

[pwestin, 2014/03/03 23:35:47]

Mikhal based on the date we have seen in testing I think we should ignore the
first value

[mikhal1, 2014/03/04 00:02:37]

True, just thought of it as I was responding to hguihot.
On 2014/03/03 23:35:47, pwestin wrote:

     }
   }
   // Reset |time_incoming_packet_updated_| to enable a future measurement.