Allow setting memory limits on media::DemuxerStream

media/filters/ffmpeg_demuxer.cc

 // Copyright (c) 2012 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/ffmpeg_demuxer.h"
 
 #include <algorithm>
 
 #include "base/base64.h"
 #include "base/bind.h"
@@ skipping 463 matching lines @@
 VideoDecoderConfig FFmpegDemuxerStream::video_decoder_config() {
   DCHECK(task_runner_->BelongsToCurrentThread());
   CHECK_EQ(type_, VIDEO);
   return video_config_;
 }
 
 VideoRotation FFmpegDemuxerStream::video_rotation() {
   return video_rotation_;
 }
 
+size_t FFmpegDemuxerStream::GetMemoryLimit() const {

[ddorwin, 2015/06/20 01:50:26]

Moving part of the discussion from
https://codereview.chromium.org/1182183004/diff/40001/public/platform/WebMedi...
here because it's not relevant to the interface but should be discussed

On 2015/06/17 21:39:44, servolk wrote:
...
I'm curious how similar the memory usage is for these two types of playback and
whether it makes sense to have a uniform interface. In the MSE case, the
application downloaded data and provided it to MSE as SourceBuffers that
Chromium manages. In the .src=, Chromium decides how much data to download. It
could be in the network cache (out of the DemuxerStream's control),
BufferedDataSource, or DemuxerStream. Do you know where the bulk of the memory
usage actually is or whether it varies during playback?

Even if most memory is post-demux, that could theoretically change in the future
or across platforms and may not be something we want to expose via DemuxerStream
or to Blink.

Note that since .src= content is always muxed, separate limits for each stream
[type] (as in https://codereview.chromium.org/1182183004/) would only affect the
post-demux memory usage.

In both cases, I think it is simpler (and likely more effective) to manage each
case directly (i.e. in ChunkDemuxer and BufferedDataSource).

+  // TODO(servolk): Implement better memory limit control for FFMpegDemuxer,
+  // currently it has a hard-coded limit of 150Mb across all streams (see
+  // IsMaxMemoryUsageReached and crbug.com/343304).
+  // Also FFmpegDemuxer is always used with media::BufferDataSource, perhaps
+  // we should control buffer size via that for FFmpeg.
+  NOTIMPLEMENTED();
+  return 0;

[ddorwin, 2015/06/17 21:02:16]

What is going to happen when Blink starts using this API?

[servolk, 2015/06/17 22:13:48]

For now we are planning to use this API from Blink level only for unit tests, so
it should be fine.

[ddorwin, 2015/06/20 01:50:26]

I assume you mean layout tests?
There is nothing to prevent other code from relying on this API once you expose
it, especially over to Blink.

If you really don't expect this to be called, you need to ensure this (i.e. it
is only set via the "internal" APIs exposed for layout tests) and use
NOTREACHED() to catch bugs that expose it in other ways.

+}
+
+void FFmpegDemuxerStream::SetMemoryLimit(size_t memory_limit) {
+  // TODO(servolk): Implement better memory limit control for FFMpegDemuxer,
+  // currently it has a hard-coded limit of 150Mb across all streams (see
+  // IsMaxMemoryUsageReached and crbug.com/343304).
+  // Also FFmpegDemuxer is always used with media::BufferDataSource, perhaps
+  // we should control buffer size via that for FFmpeg.
+  NOTIMPLEMENTED();
+}
+
 void FFmpegDemuxerStream::SetLiveness(Liveness liveness) {
   DCHECK(task_runner_->BelongsToCurrentThread());
   DCHECK_EQ(liveness_, LIVENESS_UNKNOWN);
   liveness_ = liveness;
 }
 
 base::TimeDelta FFmpegDemuxerStream::GetElapsedTime() const {
   return ConvertStreamTimestamp(stream_->time_base, stream_->cur_dts);
 }
 
@@ skipping 809 matching lines @@
 
 void FFmpegDemuxer::SetLiveness(DemuxerStream::Liveness liveness) {
   DCHECK(task_runner_->BelongsToCurrentThread());
   for (const auto& stream : streams_) {  // |stream| is a ref to a pointer.
     if (stream)
       stream->SetLiveness(liveness);
   }
 }
 
 }  // namespace media