Reducing the IPC latency for MSE video decoding

For MSE, we decode the data in the browser process. When all the data is decoded, we started to request data from the render process.
So the decoder is idle during the IPC round trip + data copy time
This may introduce some issues as this delay may impact smooth video playbacks.
This change tries to solve the above problem:
1. Divide data into 2 chunks in the browser process
2. When decoding 1 chunk, check if the chunk is reaching its end.
   If so, request data for the current chunk, and start decoding the next chunk.
3. When new data arrives, store them in the next chunk (since the current one might still be being decoded)

This change also:
1. reduced the buffered data size at the browser side
2. fixes crbug.com/306314 if there is pending data requests across release()/start()
3. fixed all the unit tests behaviors. The new approach should be well tested by all the unit tests we have.

BUG=306314

Review URL: https://codereview.chromium.org/196133020

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@258419 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 2 insertions, 2 deletions

diff --git a/content/renderer/media/android/media_source_delegate.cc b/content/renderer/media/android/media_source_delegate.cc
index 88addce..563240e 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;
 
 const uint8 kVorbisPadding[] = { 0xff, 0xff, 0xff, 0xff };