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

webrtc/media/base/videosourceinterface.h

 /*
  *  Copyright (c) 2016 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
@@ skipping 10 matching lines @@
 struct VideoSinkWants {
   // Tells the source whether the sink wants frames with rotation applied.
   // By default, any rotation must be applied by the sink.
   bool rotation_applied = false;
 
   // Tells the source that the sink only wants black frames.
   bool black_frames = false;
 
   // 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>
 class VideoSourceInterface {
  public:
   virtual void AddOrUpdateSink(VideoSinkInterface<VideoFrameT>* sink,
                                const VideoSinkWants& wants) = 0;
   // RemoveSink must guarantee that at the time the method returns,
   // there is no current and no future calls to VideoSinkInterface::OnFrame.
   virtual void RemoveSink(VideoSinkInterface<VideoFrameT>* sink) = 0;
 
  protected:
   virtual ~VideoSourceInterface() {}
 };
 
 }  // namespace rtc
 #endif  // WEBRTC_MEDIA_BASE_VIDEOSOURCEINTERFACE_H_