New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 616637 link

Starred by 1 user
Status: Fixed
Owner:
sergeyu@chromium.org
Closed: Jun 2016
Cc:
█ isheriff@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Chromoting WebRTC client does not show the initial host screen

Project Member Reported by jamiewa...@chromium.org, Jun 1 2016 
What steps will reproduce the problem?
(1) Connect to a host using WebRTC.
(2) Wait.
(3) Cause a screen update to occur on the host.

What is the expected output?
The remote screen should be visible at step 2. Instead it doesn't show up until after step 3.

Comment 1 by sergeyu@chromium.org, Jun 2 2016

Cc: isheriff@chromium.org
Labels: OS-All
Owner: sergeyu@chromium.org
Status: Assigned (was: Untriaged)
The problem is that the RTP sender may reject frames and WebRtcFrameScheduler::OnFrameEncoded() doesn't handle this properly. There is TODO about it: https://code.google.com/p/chromium/codesearch#chromium/src/remoting/protocol/webrtc_frame_scheduler.cc&l=213
Irfan, I'll try fixing this by retrying the same frame again, but please let me know if there is a better solution.

Comment 2 by isheriff@google.com, Jun 2 2016 

I think that sounds reasonable for now. We still need to understand what cause RTPSender to reject it so that we can figure out if we need an asynchronous feedback from WebRTC when it is ready to receive frames.

Comment 3 by isheriff@google.com, Jun 2 2016 

Looks like your CL took care of using the key request feedback to start
Project Member

Comment 4 by bugdroid1@chromium.org, Jun 3 2016 

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

commit ad2be8fa3ed226fa3910a13c1261f5ddd42ff385
Author: sergeyu <sergeyu@chromium.org>
Date: Fri Jun 03 09:03:21 2016

Fix WebRtcFrameScheduler to wait for first key frame request.

Previous the scheduler would start capturing before the stream is
negotiated, which was causing first few frames to be dropped. Now it
waits for the first key frame request.

BUG= 616637 

Review-Url: https://codereview.chromium.org/2035803002
Cr-Commit-Position: refs/heads/master@{#397669}

[modify] https://crrev.com/ad2be8fa3ed226fa3910a13c1261f5ddd42ff385/remoting/protocol/connection_unittest.cc
[modify] https://crrev.com/ad2be8fa3ed226fa3910a13c1261f5ddd42ff385/remoting/protocol/fake_session.cc
[modify] https://crrev.com/ad2be8fa3ed226fa3910a13c1261f5ddd42ff385/remoting/protocol/fake_session.h
[modify] https://crrev.com/ad2be8fa3ed226fa3910a13c1261f5ddd42ff385/remoting/protocol/webrtc_frame_scheduler.cc
[modify] https://crrev.com/ad2be8fa3ed226fa3910a13c1261f5ddd42ff385/remoting/protocol/webrtc_frame_scheduler.h

Comment 5 by sergeyu@chromium.org, Jun 3 2016

Status: Fixed (was: Assigned)
►

Sign in to add a comment