New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Closed: Jul 2018
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Issue 864529: Refactor WebRtcVideoCapturerAdapter

Reported by, Jul 17 2018 Project Member

Issue description

WebRtcVideoCapturerAdapter::IsScreencast will be ignored by WebRTC and CPU adaptation will always be enabled. This is because CPU adaptation is required for simulcast screenshare.

This is fine because resolution will maintained for screenshare and for relevant content hints because they are being signaled to webrtc via VideoTrack here:

This sets sets degradation preference to maintain resolution and then sink wants will never be called with maximum pixels count.

That change, however, will break some WebRtcVideoCapturerAdapter tests because they assume content hints are respected by VideoAdapter.

Comment 1 by, Jul 17 2018

I am removing the following tests:
WebRtcVideoCapturerAdapterTest.ScreencastAdapterAdaptsContentHintFluid WebRtcVideoCapturerAdapterTest.ScreencastAdapterDoesNotAdaptContentHintDetailed

Comment 2 by, Jul 17 2018

+hta@ as this sounds like it might break This code path being removed uses WebRtcVideoCapturerAdapter::ShouldAdaptResolution() which is how content hints are implemented.

You should probably not remove those tests either unless content hint code paths are otherwise covered. Please do not submit this removal without hta@'s approval.

Comment 3 by, Jul 17 2018

xref, content hints are covered by  issue 653531 .

Comment 4 by, Jul 17 2018

Can you run the demo and check that it works after making your change?

The demo is here:

You have to enable experimental flags to see any effect.

Comment 5 by, Jul 18 2018

I can confirm that the demo works with the changes applied exactly as without them (detail video looks better, but more jumpy, motion video looks less detailed but more smooth).

This is because the change only enables adaptation on all the content types. However, content hints are ultimately converted to degradation preference and webrtc doesn't scale down detail-video and doesn't reduce fps for motion-video.

Comment 6 by, Jul 18 2018

Also, before the change webrtc didn't ever drop frames or scaled down on detail-video and screenshare. It was fine if we had only 5fps, but if CPU adaptation was ever needed, it didn't happen at all. Now degradation preference "maintain resolution" would be set and video adapter actually would kick in and drop some frames.

Comment 7 by, Jul 18 2018

Project Member
The following revision refers to this bug:

commit 90665ce020b9c4959dd9ba4a838e10cd04ea2627
Author: Ilya Nikolaevskiy <>
Date: Wed Jul 18 07:55:28 2018

Disable failing WebRtcVideoCapturerAdapter tests

Bug:  864529 
Change-Id: I2393217288491a145139c56c7ec1512d2516da18
Commit-Queue: Ilya Nikolaevskiy <>
Reviewed-by: Sergey Ulanov <>
Cr-Commit-Position: refs/heads/master@{#575972}

Comment 8 by, Jul 18 2018

Thanks, that addresses it perfectly for me. I was just concerned about this case being missed.

Comment 9 by, Jul 23 2018

For context, what i am trying to do is to enable cpu adaptation for screenshare (reduced framerate).

My changes shouldn't break content hints. Before we just disabled all adaptation for screenshare and content hints piggybacked on that (signaling that detail realtime video is screenshare).

However, simply removing that check doesn't break hints, but rather enables cpu adaptation to drop frames for detail video (which was impossible before).

Content hints are propagated to both adapter and video track here:

From video track it ultimately ends up here:

In turn, this marks detail video as screenshare here:

Which will force maintain_resolution degradation preference here:

Because chrome always asks for balanced degradation preference here:

So, the only situation which breaks content hints is when we receive both detail_video and maintain_frame-rate degradation preference (which is contradictory, right?)

Maintain_resolution degradation preference will never pass max_pixel constraints to video adapter, and therefore, video will never be down scaled even if adapt() call is made in video capturer.

Comment 10 by, Jul 23 2018

I think maintain framerate as degradationPreference should take precedence over the content hint, so that sounds correct to me.

We are allowed to do other things with the content hint (change QP values springs to mind for instance) but not when they are in direct conflict with other settings.

Comment 11 by, Jul 26 2018

Project Member
The following revision refers to this bug:

commit 6c688a55956c3f6d5ffeeaef0a0098d7af868761
Author: Ilya Nikolaevskiy <>
Date: Thu Jul 26 06:27:13 2018

WebRtc Capturer Adapter: don't confuse screenshare and content hints

TESTING=manual using

Bug:  864529 
Change-Id: I7ca26888773922117848f2462cf03b7d9e28295a
Reviewed-by: Harald Alvestrand <>
Reviewed-by: Henrik Boström <>
Commit-Queue: Ilya Nikolaevskiy <>
Cr-Commit-Position: refs/heads/master@{#578218}

Comment 12 by, Jul 30 2018

Status: Fixed (was: Assigned)
Now there's no confusion between screenshare and content hints in webrtc video capturer.

Comment 13 by, Aug 27

Labels: M-70

Comment 14 by, Dec 14

Project Member
The following revision refers to this bug:

commit f32bbd8e61c3256c23f5f16826b8c7ae8d1dc233
Author: Niels Möller <>
Date: Fri Dec 14 09:26:55 2018

Delete remnants of ContentHint handling in WebRtcVideoCapturerAdapter

The |content_hint_| member is unused since

Deletes wiring in MediaStreamVideoWebRtcSink, as a preparation for
replacing WebRtcVideoCapturerAdapter (a subclass of
cricket::VideoCapturer) with an implementation of

Bug:  864529 ,  webrtc:6353 
Change-Id: I48972c63a6c69ceb859fb11fcad98d6faefac524
Reviewed-by: Sergey Ulanov <>
Commit-Queue: Niels Möller <>
Cr-Commit-Position: refs/heads/master@{#616620}

Sign in to add a comment