Change rtc::VideoSinkWants to have target and a max pixel count

webrtc/media/base/videosourceinterface.h

Index: webrtc/media/base/videosourceinterface.h
diff --git a/webrtc/media/base/videosourceinterface.h b/webrtc/media/base/videosourceinterface.h
index bae02c8d0fc3c453d199aa7853b08ecde299e136..0ea1c60abfa389e5bc236925e25d9bae74e2886d 100644
--- a/webrtc/media/base/videosourceinterface.h
+++ b/webrtc/media/base/videosourceinterface.h
@@ -28,12 +28,12 @@ struct VideoSinkWants {
 
   // Tells the source the maximum number of pixels the sink wants.
   rtc::Optional<int> max_pixel_count;
-  // Like |max_pixel_count| but relative to the given value. The source is
-  // requested to produce frames with a resolution one "step up" from the given
-  // value. In practice, this means that the sink can consume this amount of
-  // pixels but wants more and the source should produce a resolution one
-  // "step" higher than this but not higher.
-  rtc::Optional<int> max_pixel_count_step_up;
+  // Tells the source the desired number of pixels the sinks wants. This will
+  // typically be used when stepping the resolution up again when conditions
+  // have improved after an earlier downgrade. The source should select the
+  // closest resolution to this pixel count, but if max_pixel_count is set, it
+  // still sets the absolute upper bound.
+  rtc::Optional<int> target_pixel_count;

[nisse-webrtc, 2017/02/02 15:34:02]

Using this to step up has the potential failure mode that we set a
target_pixel_count higher than the current count, but the current count happens
to be the closest possible so the source makes no change.

It would make sense to me to also have a min_pixel_count, which you could set to
just slighly above the current count to force a change. Precendence  in case of
conflicts, from higher to lower, would be

max_pixel_count
min_pixel_count
target_pixel_count

I think that should be expressive enough. But if it works for now without
min_pixel_count, there's no need to add it now.

[sprang_webrtc, 2017/02/03 13:51:46]

Agree that a lower bound would be good as well. For now it works, since
VideoAdapter is, as far as I can tell, the only implementation using the
sinkwants to scale.
I omitted min_pixel_count in order to not have to change too many things at
once. I might add it before long, depending on how the framerate limits turn
out.
Good enough for now?

 };
 
 template <typename VideoFrameT>