Reducing the IPC latency for MSE video decoding

content/renderer/media/android/media_source_delegate.cc

Index: content/renderer/media/android/media_source_delegate.cc
diff --git a/content/renderer/media/android/media_source_delegate.cc b/content/renderer/media/android/media_source_delegate.cc
index 1654e1314e0c3e7eb87d9bdd43f53bd79e1b3277..b44863196f7c99351b75576c034238db2d9a6159 100644
--- a/content/renderer/media/android/media_source_delegate.cc
+++ b/content/renderer/media/android/media_source_delegate.cc
@@ -31,8 +31,8 @@ using blink::WebString;
 namespace {
 
 // The size of the access unit to transfer in an IPC in case of MediaSource.
-// 16: approximately 250ms of content in 60 fps movies.
-const size_t kAccessUnitSizeForMediaSource = 16;
+// 4: approximately 64ms of content in 60 fps movies.
+const size_t kAccessUnitSizeForMediaSource = 4;

[wolenetz, 2014/03/18 21:14:47]

nit (mostly just curious): why not 16? (or 8 since we're doubling the number of
"in-flight" chunks)? Smaller numbers here may reduce some of the browser seeking
failing to seek to target due to GC in the underlying chunkdemuxer. Is there a
drop in latency and rebuffering/janky playback delays with this change to two
chunks but overall half the previous access units in flight?

[qinmin, 2014/03/19 02:45:22]

This is mainly to reduce the memory usage.
We currently store 16 AUs in browser process, and each time also requesting 16.
By reducing the AU size to 4, we can only store 8 AUs in the browser process. I
did not observe any rebuffering/janky differences between 4 and 8

On 2014/03/18 21:14:47, wolenetz wrote:

 
 const uint8 kVorbisPadding[] = { 0xff, 0xff, 0xff, 0xff };