Cast: First stab at implementing adaptive latency

media/cast/sender/video_sender.cc

Index: media/cast/sender/video_sender.cc
diff --git a/media/cast/sender/video_sender.cc b/media/cast/sender/video_sender.cc
index f4dcb6e020687f071aaaf10fce0776fe5c9b51c4..425ae3131609fad92541c3bd4c01f3817611485a 100644
--- a/media/cast/sender/video_sender.cc
+++ b/media/cast/sender/video_sender.cc
@@ -19,6 +19,8 @@
 namespace media {
 namespace cast {
 
+const int kRoundTripsNeeded = 4;
+
 // Note, we use a fixed bitrate value when external video encoder is used.
 // Some hardware encoder shows bad behavior if we set the bitrate too
 // frequently, e.g. quality drop, not abiding by target bitrate, etc.
@@ -29,7 +31,8 @@ VideoSender::VideoSender(
     const CastInitializationCallback& initialization_cb,
     const CreateVideoEncodeAcceleratorCallback& create_vea_cb,
     const CreateVideoEncodeMemoryCallback& create_video_encode_mem_cb,
-    CastTransportSender* const transport_sender)
+    CastTransportSender* const transport_sender,
+    const PlayoutDelayChangeCB& playout_delay_change_cb)
     : FrameSender(
         cast_environment,
         false,
@@ -38,11 +41,13 @@ VideoSender::VideoSender(
         kVideoFrequency,
         video_config.ssrc,
         video_config.max_frame_rate,
-        video_config.target_playout_delay,
+        video_config.min_playout_delay,
+        video_config.max_playout_delay,
         NewFixedCongestionControl(
             (video_config.min_bitrate + video_config.max_bitrate) / 2)),
       frames_in_encoder_(0),
       last_bitrate_(0),
+      playout_delay_change_cb_(playout_delay_change_cb),
       weak_factory_(this) {
   cast_initialization_status_ = STATUS_VIDEO_UNINITIALIZED;
   VLOG(1) << "max_unacked_frames is " << max_unacked_frames_
@@ -82,7 +87,11 @@ VideoSender::VideoSender(
   transport_config.ssrc = video_config.ssrc;
   transport_config.feedback_ssrc = video_config.incoming_feedback_ssrc;
   transport_config.rtp_payload_type = video_config.rtp_payload_type;
-  transport_config.stored_frames = max_unacked_frames_;
+  transport_config.stored_frames =
+      std::min(kMaxUnackedFrames,
+               1 + static_cast<int>(max_playout_delay_ *
+                                    max_frame_rate_ /
+                                    base::TimeDelta::FromSeconds(1)));
   transport_config.aes_key = video_config.aes_key;
   transport_config.aes_iv_mask = video_config.aes_iv_mask;
 
@@ -125,6 +134,12 @@ void VideoSender::InsertRawVideoFrame(
       "rtp_timestamp", rtp_timestamp);
 
   if (ShouldDropNextFrame(capture_time)) {
+    base::TimeDelta new_target_delay = std::min(
+        current_round_trip_time_ * kRoundTripsNeeded,

[Alpha Left Google, 2014/09/11 01:24:26]

Have you considered applying a low pass filter? Or rate limit the frequency we
change the playout delay?

[hubbe, 2014/09/11 19:17:19]

My original upload used a sliding window of RTT reports for this. However, in my
manual testing(*), I found that this was unhelpful as it has the effect of
stepping up the delay slowly over time, which causes lots of skipped frames
until it stabilizes.

Using the latest rtt tends to directly jump to a larger, but still fairly
reasonable value, which means that it stabilizes faster. In real life, this
could be too aggressive, but we really need more testing to find out.

As for rate limiting: If rate limiting is needed, that just means that the
formula is not aggressive enough in raising the delay. Ideally, this should only
happen *once*, or when network conditions becomes significantly worse, so why
would we need any rate limiting?

* I tested setting min delay to 10 ms and max delay to 1000 ms and  ran it
through the tap_proxy to see how it adjusts.

+        max_playout_delay_);
+    if (new_target_delay > target_playout_delay_) {
+      playout_delay_change_cb_.Run(new_target_delay);
+    }
     VLOG(1) << "Dropping frame due to too many frames currently in-flight.";
     return;
   }