Does it happen on wired networking as well?

@Jansson: Yes it is behaving the same using wired network. 

Vasant@ : Check you can supply a video of this issue. 

This is not reproducible in Zako and Tricky.


65.0.3325.35 / 10323.9.0 Zako, Tricky

Vasant@ - Check it in the same device and if not reproducible, please close it.

This issue is available in Reks.

65.0.3325.35 / 10323.9.0.

Seems like device specific issue. Not reproducible in two chromeboxes as of now. 

terelius, could you help assess if this is likely to be the same CPU adaptation issue as the other one you looked at? In that case I think we should dupe.

I believe that the underlying problem is that the Chromebook (~2 years old, not high-end but not terrible either, iirc) is being force fed 1280 HD video by the MacBook Pro. The decoder in not able to keep up. This seems to cause several symptoms and side effects.

We do not have any way to signal CPU/GPU limitation back to the sender on the webrtc level, so this would have to be done by the application.

This issue is not reproducible in Reks now. Verified in few old builds too.
In winky it is 100% reproducible. 

VP9 observation:
googFrameHeightReceived: ~630
googFrameWidthReceived: ~1250
Incoming video from Macbook pro has partially different speed. sometimes very fast and some times delayed.

The following details are the summary of tests performed in winky. 

Meet call:
googFrameHeightReceived: ~330
googFrameWidthReceived: ~600
Note: Video of chromebook sent to macbook has bad video (bad quality with grains). Incoming quality in macbook is quite good. (ie video sent from macbook pro).

VP8 call:
googFrameHeightReceived: ~330
googFrameWidthReceived: ~660
Note: Lots of delay was observed in the video from macbook. Felt like almost watching a video at 0.5x speed. At some point incoming video is hanged. On the other side in macbook everything looks fine. 

H264 call:
googFrameHeightReceived: ~330
googFrameWidthReceived: ~660
Note: Incoming video from Macbook pro has partially different speed. sometimes very fast and some times delayed.

Chrome version: 65.0.3325.56 10323.21.0

Summary of the investigation:
Macbook Pro is sending 720p video to a resource limited ChromeBook via apprtc.
If it takes the 100ms to decode a single frame, then webrtc will play 10 frames per second. This will be slow motion if the original stream is captured at more than 10 fps.

Frames that have not yet been decoded are stored in a buffer. If the buffer becomes full, any new frames will be dropped. This should result in a keyframe request, which will result in a "jump" back to sync.

For now, the application is responsible for signaling CPU limitations to the sender. apprtc does not do this. If the sender does sends at a higher rate than the receiver can decode, we expect to see issues with incoming video but also with outgoing streams because the encoder and other parts might be CPU starved by the decoder.

philipel@ mentioned an issue where in certain conditions it might get stuck in an undecodable state when the buffer is full. Philip, could you please look into ensuring that the frame buffer always can recover?

This issue is reproducible in Cyan device 65.0.3325.65 / 10323.30.0.

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/9771c5050d4997b4474ba6e2aca9958d9b5c875c

commit 9771c5050d4997b4474ba6e2aca9958d9b5c875c
Author: philipel <philipel@webrtc.org>
Date: Tue Mar 06 09:11:11 2018

Clear the FrameBuffer if it's full and a keyframe is being inserted.

Bug:  webrtc:7705 ,  webrtc:8593 , chromium:706599,  chromium:807624 
Change-Id: Ie4e3e217bc2930fe511f8b6ad3a36afed484ab5f
Reviewed-on: https://webrtc-review.googlesource.com/59321
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22304}
[modify] https://crrev.com/9771c5050d4997b4474ba6e2aca9958d9b5c875c/modules/video_coding/frame_buffer2.cc
[modify] https://crrev.com/9771c5050d4997b4474ba6e2aca9958d9b5c875c/modules/video_coding/frame_buffer2_unittest.cc

Philipel, are you going to make more changes? If not please mark as fixed.

Vasan, if its marked as fixed, could you verify that the issue is fixed in Canary?

This main issue (long delay and uneven playout speed) is not supposed to have been fixed. The CL fixes a side effect where the video could end up completely frozen.

I don't we should consider this as a bug anymore (at least not in WebRTC), it's simply weak hardware not keeping up with the incoming stream. Closing.