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
Make it just like MP4, WebM and all the others new demuxers.
Additionally, make the ogg related preferences part of MediaPrefs.
MozReview-Commit-ID: DTedHyIMv9I
--HG--
extra : rebase_source : 8bfdf971993281454776a7c4fa644c9fc7c5ee8c
Make it just like MP4, WebM and all the others new demuxers.
Additionally, make the ogg related preferences part of MediaPrefs.
MozReview-Commit-ID: DTedHyIMv9I
--HG--
extra : rebase_source : 5ab806335b4ad17b04a20e37caf87eeb37f68bed
In bug 1258870 I changed the media code so that we dropped all late video
frames. Without this, our A/V sync was broken when the decode was struggling
to keep up, and we weren't reporting dropped frames when the decode couldn't
keep up, and so players couldn't adapt to a bitrate which the decode could keep
up on.
However, dropping all late frames broke talos tests which relied on the old
behaviour of us rendering video frames that were late. So this patch adds a
pref to cause the frame dropping code to not drop the last frame in the
queue, so there will always be something for the compositor to composit. This
means talos will once again be able to test how fast it can composit frames
that aren't supposed to be drawn.
The pref is media.ruin-av-sync.enabled.
It defaults to false.
MozReview-Commit-ID: J3VvpzoDRmI
--HG--
extra : rebase_source : ee24f37f201ef266e0894ca2c5afda498629ec0a