Increase Mojo video buffer capacity to 3MB

media/mojo/common/mojo_decoder_buffer_converter.cc

Index: media/mojo/common/mojo_decoder_buffer_converter.cc
diff --git a/media/mojo/common/mojo_decoder_buffer_converter.cc b/media/mojo/common/mojo_decoder_buffer_converter.cc
index 77cf82958442f2da14b1b933d88b2a929615c23c..d84ee810354a88cce0bca418ce4b815d37f7775b 100644
--- a/media/mojo/common/mojo_decoder_buffer_converter.cc
+++ b/media/mojo/common/mojo_decoder_buffer_converter.cc
@@ -29,10 +29,10 @@ std::unique_ptr<mojo::DataPipe> CreateDataPipe(DemuxerStream::Type type) {
     // TODO(timav): Consider capacity calculation based on AudioDecoderConfig.
     options.capacity_num_bytes = 512 * 1024;
   } else if (type == DemuxerStream::VIDEO) {
-    // Video can get quite large; at 4K, VP9 delivers packets which are ~1MB in
-    // size; so allow for some head room.
+    // Video can get quite large; at 4K, VP9 delivers packets which are larger

[xhwang, 2016/09/27 16:38:12]

nit: "which are larger than 2MB" sounds like all packets are larger than 2MB.
How about something like "which could be larger than .."?

[servolk, 2016/09/27 17:05:18]

Done.

+    // than 2MB in size; so allow for some head room.
     // TODO(xhwang, sandersd): Provide a better way to customize this value.
-    options.capacity_num_bytes = 2 * (1024 * 1024);
+    options.capacity_num_bytes = 3 * (1024 * 1024);

[xhwang, 2016/09/27 16:38:12]

When it's 2MB, I wonder whether we will have performance issue copying the data
into and out of the message pipe. Do you see any problem there?

[servolk, 2016/09/27 17:05:18]

AFAIR IPC performance has never been a performance bottleneck for us. The
bottleneck for media streaming is typically network bandwidth and IPC
performance is typically orders of magnitude faster.
So I'm not concerned about performance here. What I'm concerned about is that
perhaps even 3MB could be not enough for some high-bitrate videos, so perhaps a
better fix would be to allow partial buffer transfers through IPC rather than
blindly hardcoding the capacity. But that would be a much riskier fix, which we
probably wouldn't take into Chromecast until we get a chance to bake/test it for
some time.

   } else {
     NOTREACHED() << "Unsupported type: " << type;
     // Choose an arbitrary size.