Experiment with VP8E_SET_SCREEN_CONTENT_MODE. |
|
Issue descriptionCurrently chromoting host forces the encoder to high quantizer values for big frames, see https://codesearch.chromium.org/chromium/src/remoting/protocol/webrtc_frame_scheduler_simple.cc?l=178 Similar feature is implemented in VP8 and can be enabled with vpx_codec_control(&codec, VP8E_SET_SCREEN_CONTENT_MODE, 2) It would be great to remove that logic from chromoting and use the VP8 flag instead if the flag provides similar performance (which should be easy to verify with remoting_perftests).
,
Oct 2
I tried this experiment briefly, but found that the VP8 encoder silently drops the frame when the "big frame" condition is detected. Then the next frame would be encoded at the new (large) quantizer setting. This works if the capture source is constantly generating regular frames. But it breaks the Chromoting scheduler, since each encoded frame triggers scheduling of the next capture, and the cycle gets broken by a silently-dropped frame. So we would need to be notified of a dropped frame somehow. Alternatively, VP9 (reportedly) allows you to specify whether you want to re-encode the current frame, or drop the frame and encode the next at high-Q. The first option works better for our scheduler. |
|
►
Sign in to add a comment |
|
Comment 1 by jamiewa...@chromium.org
, Oct 2Status: Assigned (was: Untriaged)