Create the new class "BackgroundVideoDecodingPermissionObserver" to handle the
suspended request sent from the front end side.
We would do registration on startup and deregistration on shutdown of MediaDecoder.
MozReview-Commit-ID: 1UwHA7YuVN3
--HG--
extra : rebase_source : a0bc22999fbf799cd25da8ec423d9f03acc9e8e2
Retrieve pref from MediaPrefs, which is more efficient than
Preferences::GetInt().
Also refactored computations to avoid unnecessary type conversions.
MozReview-Commit-ID: Ii27lthRRNI
--HG--
extra : rebase_source : d1ea46060cd2c35b7fd07a191184c0318187c080
Don't go over the lowest of 'media.memory_caches_combined_limit_kb'
(kilobytes) or 'media.memory_caches_combined_limit_pc_sysmem' (percents of
system memory).
Added more logging around creation/destruction of MediaCaches.
MozReview-Commit-ID: Cdz4ycyn1RR
--HG--
extra : rebase_source : 63168234f186c3ef9c0289a189a647d67d8526a4
8KB by default, otherwise using the next power of two from the given
media.cache.resource-index (but staying within 32B-128KB).
'0' means we don't want to use caching.
MozReview-Commit-ID: 8LmS15Ft2MA
--HG--
extra : rebase_source : 992f377a07b7ab173a64fcfbfe45df1da87df31e
Defer determining whether we have usable decoders to an off-main thread in
order to avoid janking the main thread.
MozReview-Commit-ID: Ape5zEBBMrz
--HG--
extra : rebase_source : 1b77046ebb7bb2d4ff1ba53afce904d3de45c335
Currently we call HTMLMediaElement.canPlayType() in a JS function called
shortly after startup in order to collect telemetry as to how many of our users
don't have functioning decoders.
Unfortunately, HTMLMediaElement.canPlayType() checks whether we can play a
codec by instantiating a decoder, and this requires us to load the system
decoding libraries from disk. This requires disk I/O, which can cause jank. We
have some BHR reports showing that canPlayType can hang for > 8 seconds to back
this up.
So move the collection of this telemetry to an idle service observer, so that
we only collect this when the user is idle, and do it on a non-main thread so
it is less likely to cause jank.
MozReview-Commit-ID: HJQawmRxz
--HG--
extra : rebase_source : f5a8596fd9de770abd20e1a3e8ac0bcbb5b48599
In addition to the returned MediaResult, a special number-of-tracks value
(not just 0) indicates an unrecoverable error.
For Rust-vs-Stagefright comparison purposes, an error is considered the same
as 0 (because Stagefright never returns errors, but Rust may, so complaining
about that would be too noisy, and useless to us.)
MozReview-Commit-ID: IwadWSOIWr4
--HG--
extra : rebase_source : 29f53ee6a02a0431adb0b615a122a4e7b480108c
If 'media.playback.warnings-as-errors' is true, demuxing and decoding warnings
(i.e., non-fatal errors) will be treated as errors, causing playback to fail.
Currently set to false by default.
This could be later changed to catch and diagnose more issues.
MozReview-Commit-ID: BTaZ6TbIbNG
--HG--
extra : rebase_source : bacc24a46f588dd344e6d46178ae2d2c58882fcb
Makes transfer of samples between the content and CDM processes use shmems.
The Chromium CDM API requires us to implement a synchronous interface to supply
buffers to the CDM for it to write decrypted samples into. We want our buffers
to be backed by shmems, in order to reduce the overhead of transferring decoded
frames. However due to sandboxing restrictions, the CDM process cannot allocate
shmems itself. We don't want to be doing synchronous IPC to request shmems
from the content process, nor do we want to have to do intr IPC or make async
IPC conform to the sync allocation interface. So instead we have the content
process pre-allocate a set of shmems and give them to the CDM process in
advance of them being needed.
When the CDM needs to allocate a buffer for storing a decrypted sample, the CDM
host gives it one of these shmems' buffers. When this is sent back to the
content process, we copy the result out (uploading to a GPU surface for video
frames), and send the shmem back to the CDM process so it can reuse it.
We predict the size of buffer the CDM will allocate, and prepopulate the CDM's
list of shmems with shmems of at least that size, plus a bit of padding for
safety. We pad frames out to be the next multiple of 16, as we've seen some
decoders do that.
Normally the CDM won't allocate more than one buffer at once, but we've seen
cases where it allocates two buffers, returns one and holds onto the other. So
the minimum number of shmems we give to the CDM must be at least two, and the
default is three for safety.
MozReview-Commit-ID: 5FaWAst3aeh
--HG--
extra : rebase_source : a0cb126e72bfb2905bcdf02e864dc654e8340410
Make it available if either FFmpeg or FFVPX is configured
MozReview-Commit-ID: 7VTWQ7km4tV
--HG--
extra : rebase_source : 453db0336f47f6dcd657c33345d3894aaa54f882
This means we can isolate whether a playback failure is in
the audio or video stream.
MozReview-Commit-ID: G4broHPaAkX
--HG--
extra : rebase_source : a3648a305734cda1b2205fda96009099203a0310
Now that we're not supporting Adobe EME anymore, we don't need to
provide a mechanism for GMPs to block browser shutdown.
MozReview-Commit-ID: KUC94IBQiod
--HG--
extra : rebase_source : ed521f28e272de11b2d0c4546b98baf6bd7c6e72
If pref "media.wmf.skip-blacklist" is true, disable D3D blacklisting based on
"media.wmf.disable-d3d9-for-dlls" and "media.wmf.disable-d3d11-for-dlls".
MozReview-Commit-ID: IothZlUnK7h
--HG--
extra : rebase_source : 1731b39808526fce70d84342a016bd25b6cd8571
This removes the ability for ClearKey to instantiate persistent-license
sessions using the EME APIs.
MozReview-Commit-ID: FXj5YORxpas
--HG--
extra : source : b69b2435f1059a5c7b1dd26947ea500b381ec7f0
If "media.libavcodec.allow-obsolete" is set to true, the checks for older
libavcodec library versions are ignored.
MozReview-Commit-ID: HBhHfFomsrr
--HG--
extra : rebase_source : 6bfe06bd4354fcda90d7d33bedcbd176663cab31
If "media.libavcodec.allow-obsolete" is set to true, the checks for older
libavcodec library versions are ignored.
MozReview-Commit-ID: HBhHfFomsrr
--HG--
extra : rebase_source : 2f42348018b19d20be64001df737b342e1813274
