[remoting host] Remove limitations added for video-freezing issues

Some limitations were added, because they were believed to mitigate
the video-freezing problems with WebRTC connections. Now that the
underlying problems have been addressed, these limitations can be
removed.

Max bitrate is increased to 100Mbps from 20Mbps, undoing
crrev.com/a975bd60

Empty frames are sent every 2s instead of 200ms, to address
crbug.com/803599. Empty frames were introduced in
crrev.com/a6a3f1e8

Bug: 773549, 803599
Change-Id: I5c463d12d8935a63792656c7e79586bec0caed69
Reviewed-on: https://chromium-review.googlesource.com/907591
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537921}

remoting/protocol/webrtc_frame_scheduler_simple.cc

@@ -41,9 +41,13 @@ const int kBigFrameThresholdPixels = 300000;
 // encoded "big" frame may be too large to be delivered to the client quickly.
 const int kEstimatedBytesPerMegapixel = 100000;
 
-// Minimum interval between frames needed to keep the connection alive.
+// Minimum interval between frames needed to keep the connection alive. The
+// client will request a key-frame if it does not receive any frames for a
+// 3-second period. This is effectively a minimum frame-rate, so the value
+// should not be too small, otherwise the client may waste CPU cycles on
+// processing and rendering lots of identical frames.
 constexpr base::TimeDelta kKeepAliveInterval =
-    base::TimeDelta::FromMilliseconds(200);
+    base::TimeDelta::FromMilliseconds(2000);
 
 int64_t GetRegionArea(const webrtc::DesktopRegion& region) {
   int64_t result = 0;

remoting/protocol/webrtc_frame_scheduler_unittest.cc

@@ -91,7 +91,7 @@ TEST_F(WebrtcFrameSchedulerTest, EmptyFrameUpdate_ShouldNotBeSentImmediately) {
   EXPECT_FALSE(result);
 };
 
-TEST_F(WebrtcFrameSchedulerTest, EmptyFrameUpdate_ShouldBeSentAfter200ms) {
+TEST_F(WebrtcFrameSchedulerTest, EmptyFrameUpdate_ShouldBeSentAfter2000ms) {
   // Identical to the previous test, except it waits a short amount of time
   // before the empty frame update.
   auto video_channel_observer =
@@ -103,9 +103,9 @@ TEST_F(WebrtcFrameSchedulerTest, EmptyFrameUpdate_ShouldBeSentAfter200ms) {
   // Initial capture, full frame.
   frame.mutable_updated_region()->SetRect(DesktopRect::MakeWH(1, 1));
   scheduler_->OnFrameCaptured(&frame, &out_params);
-  // Wait more than 200ms.
+  // Wait more than 2000ms.
   scheduler_->SetCurrentTimeForTest(now_ +
-                                    base::TimeDelta::FromMilliseconds(300));
+                                    base::TimeDelta::FromMilliseconds(3000));
   // Empty frame.
   frame.mutable_updated_region()->Clear();
   bool result = scheduler_->OnFrameCaptured(&frame, &out_params);

remoting/protocol/webrtc_transport.cc

@@ -64,7 +64,7 @@ bool IsValidSessionDescriptionType(const std::string& type) {
 }
 
 void UpdateCodecParameters(SdpMessage* sdp_message, bool incoming) {
-  // Set bitrate range to 1-20 Mbps.
+  // Set bitrate range to 1-100 Mbps.
   //  - Setting min bitrate here enables padding.
   //  - The default max bitrate is 600 kbps. Increasing it allows to
   //    use higher bandwidth when it's available.
@@ -75,11 +75,9 @@ void UpdateCodecParameters(SdpMessage* sdp_message, bool incoming) {
   // TODO(isheriff): The need for this should go away once we have a proper
   // API to provide max bitrate for the case of handing over encoded
   // frames to webrtc.
-  // TODO(crbug.com/773549): Increase the max bitrate to 100Mbps when the
-  // underlying bug is fixed to handle high load at high bitrate.
   if (sdp_message->has_video()) {
     const char* kParameters =
-        "x-google-min-bitrate=1000; x-google-max-bitrate=20000";
+        "x-google-min-bitrate=1000; x-google-max-bitrate=100000";
     bool param_added = sdp_message->AddCodecParameter("VP8", kParameters);
     param_added |= sdp_message->AddCodecParameter("VP9", kParameters);
     param_added |= sdp_message->AddCodecParameter("H264", kParameters);