Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-10-16 23:05:42 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Chris Pearce 2017-07-24 16:56:24 +12:00
parent ab9e4db6d1
commit 0f1f90f2c1
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
dom/media/gmp/ChromiumCDMParent.cpp
View File

@ -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,