Experiment with more aggressive MSE GC on memory pressure

media/filters/source_buffer_state.cc

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "media/filters/source_buffer_state.h"
 
 #include <set>
 
 #include "base/callback_helpers.h"
 #include "base/command_line.h"
@@ skipping 288 matching lines @@
     uint64_t estimated_new_size = newDataSize * curr_size / total_buffered_size;
     DCHECK_LE(estimated_new_size, SIZE_MAX);
     success &= it.second->EvictCodedFrames(
         media_time, static_cast<size_t>(estimated_new_size));
   }
 
   DVLOG(3) << __func__ << " success=" << success;
   return success;
 }
 
+void SourceBufferState::OnMemoryPressure(
+    DecodeTimestamp media_time,
+    base::MemoryPressureListener::MemoryPressureLevel memory_pressure_level) {
+  // Notify video streams about memory pressure first, since video typically
+  // takes up the most memory and that's where we can expect most savings.

[chcunningham, 2017/01/25 03:47:15]

I agree about the savings, but I don't follow on the "first" part. Isn't the
effect of doing it last the same - we will still try to adjust the limits / GC
in the same way? Maybe I'm missing something

[servolk, 2017/01/25 18:06:47]

This might make a difference when the instant GC on memory pressure is enabled
(the kMSEInstantGCOnMemoryPressure feature). In that case we'll perform GC
immediately inside the it.second->OnMemoryPressure invocation. And if the memory
pressure is critical, I guess we better free up as much memory as quickly as
possible. By performing GC on video buffers first we'll be able to relieve
memory pressure quicker, than if we started with let's say audio buffers.

[chcunningham, 2017/01/25 22:21:56]

I think this is fine, I just wanted to be sure I wasn't missing something subtle
- like if doing GC of video_streams_ first was expected to reduce the
aggressiveness of GC for audio/text. Seems not.

[servolk, 2017/01/26 18:10:14]

The aggressiveness of GC for audio/text is going to be the same as for video. As
I've explained in my previous comment, the order here matters only for cases
when we do instant GC on memory pressure notifications.

+  for (const auto& it : video_streams_)
+    it.second->OnMemoryPressure(media_time, memory_pressure_level);
+  for (const auto& it : audio_streams_)
+    it.second->OnMemoryPressure(media_time, memory_pressure_level);
+  for (const auto& it : text_streams_)
+    it.second->OnMemoryPressure(media_time, memory_pressure_level);
+}
+
 Ranges<TimeDelta> SourceBufferState::GetBufferedRanges(TimeDelta duration,
                                                        bool ended) const {
   RangesList ranges_list;
   for (const auto& it : audio_streams_)
     ranges_list.push_back(it.second->GetBufferedRanges(duration));
 
   for (const auto& it : video_streams_)
     ranges_list.push_back(it.second->GetBufferedRanges(duration));
 
   for (const auto& it : text_streams_)
@@ skipping 569 matching lines @@
 }
 void SourceBufferState::OnSourceInitDone(
     const StreamParser::InitParameters& params) {
   DCHECK_EQ(state_, PENDING_PARSER_INIT);
   state_ = PARSER_INITIALIZED;
   auto_update_timestamp_offset_ = params.auto_update_timestamp_offset;
   base::ResetAndReturn(&init_cb_).Run(params);
 }
 
 }  // namespace media