Edit: Make a call between two chrome browsers and make some fast* motion

Attaching chrome debug logs for the same.

Deleted: chrome_debug.log 6.1 MB

chrome_debug.log 6.1 MB View Download

deadbeef@: can you take a look or reassign to a better owner?

Adding Video component. Question for the reporter, though: why do you not consider this expected behavior? WebRTC may degrade the resolution and/or framerate due to bandwidth and/or CPU limitations.

Both the machines are on high speed LAN. From the debug logs that I attached, I don't see any issues with bandwidth.
Also, the machine has 12 cores so no CPU limitations either.

Ah. Somehow it's still triggering the "CPU overuse" downscaling though:

[7764:21776:0203/171815.383:INFO:vie_encoder.cc(796)] CPU overuse detected. Requesting lower resolution.
[7764:21776:0203/171815.383:VERBOSE1:overuse_frame_detector.cc(385)]  Frame stats:  encode usage 264 overuse detections 1 rampup delay 40000
[7764:15992:0203/171815.414:INFO:videoadapter.cc(238)] Frame size changed: scaled 1 / out 3363 / in 3363 Changes: 1 Input: 1280x720 Scale: 3/4 Output: 960x540 i0

I also see lots of log messages like this one:

[7764:21776:0203/171815.383:VERBOSE1:vie_encoder.cc(236)] Incoming frame dropped due to that the encoder is blocked.

So if the bandwidth seems fine and the CPU is powerful enough, what might have triggered the down-scaling?  

I'm not sure myself; maybe H.264 encoding is just that strenuous. I'll leave the video team to investigate further.

In this particular set of logs attached, I see that the encoding resolution went down even when there was no overuse detected. The media_bps went considerably lower. From ~472k to ~70k to ~3.5k. The preferred_media_bitrate_bps is 666k which seems fine and the incoming REMB is also ~4MB. What might have caused the downgrade?

[8064:15272:0207/151116.926:INFO:webrtcvideoengine2.cc(2038)] VideoSendStream stats: 1285814, {input_fps: 30, encode_fps: 30, encode_ms: 8, encode_usage_perc: 25, target_bps: 666000, media_bps: 472785, preferred_media_bitrate_bps: 666, suspended: false, bw_adapted: false} {ssrc: 168261854, width: 640, height: 360, key: 3, delta: 1317, total_bps: 493896, retransmit_bps: 0, avg_delay_ms: 13, max_delay_ms: 23, cum_loss: 0, max_ext_seq: 20649, nack: 0, fir: 0, pli: 1}
[8064:11328:0207/151120.874:VERBOSE1:overuse_frame_detector.cc(385)]  Frame stats:  encode usage 24 overuse detections 0 rampup delay 10000
[8064:11328:0207/151124.582:INFO:h264_encoder_impl.cc(306)] Encoder reinitialized from 640x360 to 320x180
[8064:11328:0207/151125.874:VERBOSE1:overuse_frame_detector.cc(385)]  Frame stats:  encode usage 22 overuse detections 0 rampup delay 10000
[8064:15272:0207/151127.926:INFO:webrtcvideoengine2.cc(2038)] VideoSendStream stats: 1296814, {input_fps: 30, encode_fps: 30, encode_ms: 3, encode_usage_perc: 18, target_bps: 666000, media_bps: 69570, preferred_media_bitrate_bps: 666, suspended: false, bw_adapted: false} {ssrc: 168261854, width: 320, height: 180, key: 4, delta: 1646, total_bps: 63344, retransmit_bps: 0, avg_delay_ms: 6, max_delay_ms: 9, cum_loss: 0, max_ext_seq: 21076, nack: 0, fir: 0, pli: 1}
[8064:11328:0207/151130.875:VERBOSE1:overuse_frame_detector.cc(385)]  Frame stats:  encode usage 13 overuse detections 0 rampup delay 10000
[8064:11328:0207/151135.875:VERBOSE1:overuse_frame_detector.cc(385)]  Frame stats:  encode usage 9 overuse detections 0 rampup delay 10000
[8064:15272:0207/151138.926:INFO:webrtcvideoengine2.cc(2038)] VideoSendStream stats: 1307814, {input_fps: 30, encode_fps: 30, encode_ms: 2, encode_usage_perc: 7, target_bps: 666000, media_bps: 3696, preferred_media_bitrate_bps: 666, suspended: false, bw_adapted: false} {ssrc: 168261854, width: 320, height: 180, key: 4, delta: 1976, total_bps: 7192, retransmit_bps: 0, avg_delay_ms: 5, max_delay_ms: 7, cum_loss: 0, max_ext_seq: 21406, nack: 0, fir: 0, pli: 1}

Deleted: chrome_debug.log 5.6 MB

chrome_debug.log 5.6 MB View Download

Hi,
I want to say that I am experiencing similar issues but in my demo app the video stream is of the screen (not camera). Also if I use the Canary version there is NO downgrade to the resolution.
I have posted my scenario here: https://groups.google.com/forum/#!searchin/discuss-webrtc/tal$20kashi%7Csort:relevance/discuss-webrtc/wVDFEZTePqw/a7QRTpTmBwAJ

If you would like some more information about my scenario please ask and I will try to supply it ASAP

Hi,
Wanted to know if there is any progress made on this one?

We've also seen the exact same issue on multiple installations and hardware setups. Only slight variations to the original description is that it's not even necessary with high amounts of motion for the low resolution to happen.

Unfortunately I've not experienced it on a machine I have available for development and debugging. Reports indicate that it started to happen after the 55 -> 56 upgrade, and still happens with Canary. Attaching a chrome_debug.log for good measure, but I can't spot any new information besides what's been mentioned already: Downsizing happens without any overuse detected.

Testing on one the same installations and setups using VP8 gives expected 720p quality with roughly 60-70% cpu usage. I have observed before that H.264 is a bit slower than VP8, but certainly the difference should not be as big as this (720p vs 180p).

Deleted: chrome_debug.log 3.3 MB

chrome_debug.log 3.3 MB View Download

I have seen another issue where chrome just dropped the send bitrate in an ongoing call. But the resolution was same. Not sure if this is similar to that.
https://bugs.chromium.org/p/webrtc/issues/detail?id=7164