H264 encoder never adapts to low bandwidth by decreasing resolution
Reported by
hrun...@gmail.com,
Apr 17 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36 OPR/44.0.2510.857 Steps to reproduce the problem: 1. Make a call that can use h264 only: https://appr.tc/r/NNNNN?vrc=h264&vsc=h264 2. Put yourself in low bandwidth situation What is the expected behavior? Encoder drops the resolution to keep the bitrate What went wrong? Encoder drops framerate to the unusable values Did this work before? N/A Does this work in other browsers? N/A Chrome version: 57.0.2987.98 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 25.0 r0 Encoder can drop resolution for h264 as it does it when CPU utilization rises. But in case of bandwidth-related issue it resorts to frame drops only. This is not an issue for VP8: VP8 adapts flawlessly to the bandwidth by dropping resolution
,
Apr 17 2017
emircan@: Could you please take a look at this?
,
Apr 17 2017
CPU adaptation for HW encode is enabled again after the fix on issue 597087 landed. In Windows case here, H264 is HW accelerated and VP8 isn't. Based on the bandwidth fluctuations, we might be dropping frames inside webrtc if encoder is overshooting by a lot. I will try to measure what is happening in that BW range. We might need to include a bitrate adjuster(like we do in Mac) to accomodate that. |
|||
►
Sign in to add a comment |
|||
Comment 1 by hrun...@gmail.com
, Apr 17 2017