Video Capture: Allow suspension of individual devices.

content/renderer/media/media_stream_video_source.cc

Index: content/renderer/media/media_stream_video_source.cc
diff --git a/content/renderer/media/media_stream_video_source.cc b/content/renderer/media/media_stream_video_source.cc
index b2e550c221de1c69b55c5ac69e0779ef433807d7..0f531443b61e26566ce755385c84f5cb1dbf2ea7 100644
--- a/content/renderer/media/media_stream_video_source.cc
+++ b/content/renderer/media/media_stream_video_source.cc
@@ -393,11 +393,26 @@ void MediaStreamVideoSource::RemoveTrack(MediaStreamVideoTrack* video_track) {
     StopSource();
 }
 
+void MediaStreamVideoSource::UpdateHasConsumers(MediaStreamVideoTrack* track,
+                                                bool has_consumers) {
+  DCHECK(CalledOnValidThread());
+  const auto it =
+      std::find(suspended_tracks_.begin(), suspended_tracks_.end(), track);
+  if (has_consumers) {
+    if (it != suspended_tracks_.end())
+      suspended_tracks_.erase(it);
+  } else {
+    if (it == suspended_tracks_.end())

[emircan, 2016/09/28 17:16:24]

std::set would be a more appropriate container for |suspended_tracks_| as we
only have unique elements.

[miu, 2016/09/28 20:57:50]

Actually, no, because std::set is an ordered set. There's no requirement for
ordering here. So, that would suggest std::unordered_set, except...

There's been some interesting discussion on the Project TRIM list around
techniques for saving memory (and also increasing performance) w.r.t. our data
structures in Chromium. std::set/map are implemented using a Red-Black tree,
which is very memory inefficient. (I myself have a research project on the side
to determine whether we should replace our STL implementations of std::set/map
and friends with something else.)

Generally speaking, you should always try to use std::vector when the number of
elements in a container is guaranteed to remain small. The memory overhead is
far smaller, it's much friendlier to the CPU caches, and the linear search
(std::find) will execute much faster than the log-n search (set::find). A more
complete explanation: http://lafstern.org/matt/col1.pdf

If you're curious, I can point you at other research and discussion.

+      suspended_tracks_.push_back(track);
+  }
+  OnHasConsumers(suspended_tracks_.size() < tracks_.size());
+}
+
 void MediaStreamVideoSource::UpdateCapturingLinkSecure(
-    MediaStreamVideoTrack* track,
-    bool is_secure) {
+    MediaStreamVideoTrack* track, bool is_secure) {
+  DCHECK(CalledOnValidThread());
   secure_tracker_.Update(track, is_secure);
-  SetCapturingLinkSecured(secure_tracker_.is_capturing_secure());
+  OnCapturingLinkSecured(secure_tracker_.is_capturing_secure());
 }
 
 base::SingleThreadTaskRunner* MediaStreamVideoSource::io_task_runner() const {