This patch adds the number of dropped frames for each step of the process
(read/sink/compositor) and gives us more insight about where frames are
dropped, as opposed to the getVideoPlaybackQuality() API which gives the grand
total.
Differential Revision: https://phabricator.services.mozilla.com/D27488
There are often websites using videos without an audio track as background image or as GIF-like image. For these cases,
we don't want to hold a wakelock.
Differential Revision: https://phabricator.services.mozilla.com/D7215
HTMLMediaElement::UpdateWakeLock() is responsible for creating and releasing audio wakelock.
HTMLVideoElement::UpdateWakeLock() is responsible for creating and releasing video wakelock.
In addition, each platform would handle system wakelock properly depending on different requests.
Differential Revision: https://phabricator.services.mozilla.com/D7214
Various places in dom/ use the pattern:
already_AddRefed<NodeInfo> ni = ...;
which is supposed to be disallowed by our static analysis code, but
isn't, for whatever reason. To fix our static analysis code, we need to
eliminate instances of the above pattern.
Unfortunately, eliminating this pattern requires restructuring how Nodes
are created. Most Node subclasses take `already_AddRefed<NodeInfo>&` in
their constructors, and a few accept `already_AddRefed<NodeInfo>&&`. We
need to enforce the latter pattern consistently, which requires changing
dozens of source files.
Mostly-mechanical additions:
- Log constructions&destructions, usually by just inheriting from
DecoderDoctorLifeLogger, otherwise with explicit log commands (for internal
classes for which DecoderDoctorTraits can't be specialized),
- Log links between most objects, e.g.: Media element -> decoder -> state
machine -> reader -> demuxer -> resource, etc.
And logging some important properties and events (JS events, duration change,
frames being decoded, etc.)
More will be added later on, from just converting MOZ_LOGs, and as needed.
MozReview-Commit-ID: KgNhHSz35t0
This is necessary in order to parse style attributes using the subject
principal of the caller, rather than defaulting to the page principal.
MozReview-Commit-ID: GIshajQ28la
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
Wakelock would automatically handle the lock/unlock by listening "hidden/visible", we
don't need to handle it in HTMLVideoElement.
MozReview-Commit-ID: AcOwR2nqm6L
For knowing the wake lock usage more clearly, we should use more specific topic name.
In OSX, you can use "$ pmset -g assertions" to check all the wakelock.
In Windows, using "$ powser -energy" to generate the energy report.
MozReview-Commit-ID: rAXnkxTvLc
If TimeUnits.h includes mozilla/dom/TimeRanges.h, then the build ends up
pulling in the Gecko DOM bindings, which pulls in a whole lot of JavaScript and
DOM bindings code. That makes it trickier to import GeckoMedia into Servo, and
makes Gecko's build slower, so move the code to convert TimeIntervals into
dom::TimeRanges.
Also remove an extraneous "virtual" and add "const" to some functions in TimeRanges.
MozReview-Commit-ID: BLeehaf9gCE
This patch makes the media statistics report values with a fixed frames per second
and a dynamic dropped ratio when resistance fingerprinting is enabled. The dropped
rate is decided by the video resolution that it will report a fixed dropped rate
when the video resolution is greater than 480p. And It will report a zero dropped
rate if the video is below or equal to 480p. In addition, it adds three new prefs
that allow us to change the value of frames per second, the dropped ratio and the
threshold of target video resolution. The three prefs are
'privacy.resistFingerprinting.video_frames_per_sec', 'privacy.resistFingerprinting.video_dropped_ratio'
and 'privacy.resistFingerprinting.target_video_res'. The default values of them
are 30, 5 and 480, which means 30 frames per second, 5 percent dropped ratio and
480p.
This also adds a new helper function 'nsContentUtils::ShouldResistFingerprinting(nsIDocument* aDoc)'
for checking whether fingerprinting resistance is enabled for a given docuemnt.
If it is a chrome document, this function will indicate that fingerprinting
resistance is not enabled regardless of the pref 'privacy.resistFingerprinting'.
If it is a content document, the result will depend on the pref.
MozReview-Commit-ID: FbSuRq6Zdnn
