зеркало из https://github.com/mozilla/gecko-dev.git
ce7bb69227
The CDM process can't allocate shmems itself because it's sandboxed, so we pre-allocate shmems in the content process and send them to the GMP process for the CDM to use. Some sites seem to have encoded their content in such a way as to cause the CDM to allocate and hang onto more frames than we pre-allocate; so we run out of shmems in the GMP process, and the CDM can't allocate further buffers to return output, and we fail. So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs out of shmems, and return the result to the content process as an nsTArray. Upon receiving that, the parent will send an extra shmem to the child, to hopefully avoid the slow path again. Also increase media.eme.chromium-api.video-shmems to 4, so that we're less likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and Microsoft's EME test-drive require 4 shmems. MozReview-Commit-ID: ISQYDkTj5uY --HG-- extra : rebase_source : 92870f1adc7ae68e58b15443e4223012bdf0e39a |
||
|---|---|---|
| .. | ||
| brotli | ||
| fdlibm | ||
| freetype2 | ||
| libbz2 | ||
| libjar | ||
| libmar | ||
| libpref | ||
| woff2 | ||
| xz-embedded | ||
| zlib | ||
| moz.build | ||