New issue
Advanced search Search tips

Issue 773549 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Bug

Blocked on:
issue 804032



Sign in to add a comment

Chromoting over WebRTC becomes extremely laggy under heavy load

Project Member Reported by lambroslambrou@chromium.org, Oct 11 2017

Issue description

Problem affects Me2Me and It2Me connections over WebRTC.

When the screen is rapidly changing over a large area, this triggers a condition where the client display will freeze for several seconds, making the connection unusable.

Input injection continues to work normally - the problem is that frames get dropped due to massive packet loss.

 
Project Member

Comment 1 by bugdroid1@chromium.org, Oct 12 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a975bd60169fcce356ef61f30e3a4c448f5899e5

commit a975bd60169fcce356ef61f30e3a4c448f5899e5
Author: Lambros Lambrou <lambroslambrou@chromium.org>
Date: Thu Oct 12 01:17:14 2017

[remoting] Reduce WebRTC video max-bitrate to 20Mbps

This is a quick temporary fix to allow remoting to be usable over
WebRTC. It caps the network usage of video stream to 20Mbps to avoid
saturating the network and triggering massive packet loss.

Bug:  773549 
Change-Id: Ib41df879ebe47a6d552a892ad58e673f9986d531
Reviewed-on: https://chromium-review.googlesource.com/714296
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508198}
[modify] https://crrev.com/a975bd60169fcce356ef61f30e3a4c448f5899e5/remoting/protocol/webrtc_transport.cc

Project Member

Comment 2 by bugdroid1@chromium.org, Oct 19 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6a3f1e839e900f335350c8555a973cadce46386

commit a6a3f1e839e900f335350c8555a973cadce46386
Author: Lambros Lambrou <lambroslambrou@chromium.org>
Date: Thu Oct 19 01:37:29 2017

[remoting webrtc] Send regular keep-alive frames

If the display is unchanging, the host will normally not send any
frames to the client, which causes the client to think the video
stream is broken. The client makes FIR or PLI requests every few
seconds, resulting in unnecessary key-frames which wastes resources.

This CL fixes this by sending empty frame deltas at a capped rate
when the capturer returns empty frame updates.

The capped rate is set to a rapid value, since testing indicates
this also helps avoid laggy behavior ( crbug.com/773549 ), possibly
because of improved b/w estimation when more frames are sent.

Bug:  773894 , 773549 
Change-Id: I40da2167a86aad3d099eeb45de7c21685b6ad612
Reviewed-on: https://chromium-review.googlesource.com/724660
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509965}
[modify] https://crrev.com/a6a3f1e839e900f335350c8555a973cadce46386/remoting/protocol/webrtc_frame_scheduler_simple.cc
[modify] https://crrev.com/a6a3f1e839e900f335350c8555a973cadce46386/remoting/protocol/webrtc_frame_scheduler_simple.h

Project Member

Comment 3 by bugdroid1@chromium.org, Oct 23 2017

Labels: merge-merged-3239
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ca29a5fe00248482cd8036dfd9f2507944166661

commit ca29a5fe00248482cd8036dfd9f2507944166661
Author: Lambros Lambrou <lambroslambrou@chromium.org>
Date: Mon Oct 23 16:47:56 2017

[remoting webrtc] Send regular keep-alive frames

If the display is unchanging, the host will normally not send any
frames to the client, which causes the client to think the video
stream is broken. The client makes FIR or PLI requests every few
seconds, resulting in unnecessary key-frames which wastes resources.

This CL fixes this by sending empty frame deltas at a capped rate
when the capturer returns empty frame updates.

The capped rate is set to a rapid value, since testing indicates
this also helps avoid laggy behavior ( crbug.com/773549 ), possibly
because of improved b/w estimation when more frames are sent.

Bug:  773894 , 773549 
Change-Id: I40da2167a86aad3d099eeb45de7c21685b6ad612
Reviewed-on: https://chromium-review.googlesource.com/724660
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#509965}(cherry picked from commit a6a3f1e839e900f335350c8555a973cadce46386)
Reviewed-on: https://chromium-review.googlesource.com/733720
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#154}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/ca29a5fe00248482cd8036dfd9f2507944166661/remoting/protocol/webrtc_frame_scheduler_simple.cc
[modify] https://crrev.com/ca29a5fe00248482cd8036dfd9f2507944166661/remoting/protocol/webrtc_frame_scheduler_simple.h

Project Member

Comment 4 by bugdroid1@chromium.org, Dec 1 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2fd8366793d02827c901100f9c36b9fead900dbf

commit 2fd8366793d02827c901100f9c36b9fead900dbf
Author: Lambros Lambrou <lambroslambrou@chromium.org>
Date: Fri Dec 01 17:29:28 2017

[remoting host] Add Picture ID to VPX frames

Sending video frames with a picture ID allows the WebRTC receiver's
jitter buffer to improve the processing of frame references, instead of
relying on gaps in the packet sequence numbers. This should avoid false
detections of packet loss in the case of missing or corrupt ULPFEC
packets (when the frame could still be decoded).

This is only possible for VPX-encoded frames. For H264, jitter buffer
processing will fall back on using sequence-number gaps.

Bug:  773549 
Change-Id: I354473a60249d85a3319ec88f07124420e078b44
Reviewed-on: https://chromium-review.googlesource.com/802455
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520972}
[modify] https://crrev.com/2fd8366793d02827c901100f9c36b9fead900dbf/remoting/protocol/webrtc_dummy_video_encoder.cc
[modify] https://crrev.com/2fd8366793d02827c901100f9c36b9fead900dbf/remoting/protocol/webrtc_dummy_video_encoder.h

Blockedon: 804032
Status: Fixed (was: Assigned)
This is fixed now, with recent changes to WebRTC:

revision 788ac70c1f8a34bf375b09dee69a4e7d547dc4f9
Don't overwrite RTP packets in history within one second or 3x RTT.

revision 8b101923070864b7b5d9085ab71cc0fba3c46821
Don't overwrite packets in rtp packet history too early

revision 393e2664703351833948a30802e50d4ce101662a
Use correct RTP header length in RED generation for ULPFEC packets.

Project Member

Comment 7 by bugdroid1@chromium.org, Feb 20 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/035185dee8763d8c48e3614b739ef5594536e100

commit 035185dee8763d8c48e3614b739ef5594536e100
Author: Lambros Lambrou <lambroslambrou@chromium.org>
Date: Tue Feb 20 23:06:09 2018

[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/a975bd60169fcce356ef61f30e3a4c448f5899e5

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

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}
[modify] https://crrev.com/035185dee8763d8c48e3614b739ef5594536e100/remoting/protocol/webrtc_frame_scheduler_simple.cc
[modify] https://crrev.com/035185dee8763d8c48e3614b739ef5594536e100/remoting/protocol/webrtc_frame_scheduler_unittest.cc
[modify] https://crrev.com/035185dee8763d8c48e3614b739ef5594536e100/remoting/protocol/webrtc_transport.cc

Sign in to add a comment