Bug 1383580 - Pad estimated CDM frame sizes. r=gerald

The new video decoder in CDM version 1.4.8.970 seems to calculate its frame size
as about 1.5X of the optimal size. So increase our estimate of CDM video frame
buffer sizes by more than that so that our pre-allocated buffers should be big
enough to accomodate the allocations that the CDM requests.

This means we should be more likely to avoid the slow fallback path where we
have to transfer frames from the CDM to the content process using the non-shmem
path.

MozReview-Commit-ID: 6PT8XVCAL3E

--HG--
extra : rebase_source : a27793b033c4f50f6e15d874558dc50e1410c8be

dom/media/gmp/ChromiumCDMParent.cpp

@@ -947,8 +947,15 @@ ChromiumCDMParent::InitializeVideoDecoder(
       __func__);
   }
 
+  // The Widevine CDM version 1.4.8.970 and above contain a video decoder that
+  // does not optimally allocate video frames; it requests buffers much larger
+  // than required. The exact formula the CDM uses to calculate their frame
+  // sizes isn't obvious, but they normally request around or slightly more
+  // than 1.5X the optimal amount. So pad the size of buffers we allocate so
+  // that we're likely to have buffers big enough to accomodate the CDM's weird
+  // frame size calculation.
   const size_t bufferSize =
-    I420FrameBufferSizePadded(aInfo.mImage.width, aInfo.mImage.height);
+    1.7 * I420FrameBufferSizePadded(aInfo.mImage.width, aInfo.mImage.height);
   if (bufferSize <= 0) {
     return MediaDataDecoder::InitPromise::CreateAndReject(
       MediaResult(NS_ERROR_DOM_MEDIA_FATAL_ERR,