And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
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
--HG--
extra : rebase_source : dd7206e350e32671adc6f3b9e54ebf777251de2c
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
--HG--
extra : rebase_source : 5dba46f61d70ec647cae16383b62961ac72d2f47
(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
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Wakelock would automatically handle the lock/unlock by listening "hidden/visible", we
don't need to handle it in HTMLVideoElement.
MozReview-Commit-ID: AcOwR2nqm6L
--HG--
extra : rebase_source : 8f96b8cd908332be33ed3289dd288990da56c1c9
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
--HG--
extra : rebase_source : 42ebf204673d3c913739f64c71c24af20d37c95d
These functions didn't be used by anyone, remove them.
MozReview-Commit-ID: BLj8GsVp1gR
--HG--
extra : rebase_source : 1b7eee86c62314401c2374a2979ba2a42fda2490
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
--HG--
extra : rebase_source : 84ef054cf8fd5b4434dc761a1b0a39803d3231f5
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
--HG--
extra : rebase_source : a62a1be19d9b38520f9eed7164fb258e3354d228
totalVideoFrameCount was previously incorrectly set to the number of demuxed
frames.
According to the current W3C specs [1], it should instead be the total number of
frames that have been presented, plus frames that have been discarded.
Also added a check that discarded<=total in mochitest.
[1] https://wicg.github.io/media-playback-quality/#concepts
MozReview-Commit-ID: Gnv1roM5n0A
--HG--
extra : rebase_source : 1f018612fbaf43867f5c92e59d62d718a3b08535
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : transplant_source : %008z%D8W%EE%87%8E%E9/%2CT%26%EBvo%AE%099%A6
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : amend_source : 7eb1e87fdcbc61f2f9831fa3a6d803cc50306604
Replace the pointer of VideoFrameContainer with the pointer of MediaStreamVideoSink.
MozReview-Commit-ID: 5bqEMpemwuR
--HG--
extra : transplant_source : %9D%86%93%A6%DF%D5%9Ep%20%DF%FD%C1%E2%BA%A3Gq%1A%7E%A3
HTMLVideoElement can expose its thread-safe FrameStatistics object, so that
HTMLMediaElement can access more adequate data for its telemetry, without
having to use an intermediary (and potentially less accurate)
VideoPlaybackQuality object.
This will also help with accessing other/new FrameStatistics members later on.
MozReview-Commit-ID: AT7mEGy0zGr
--HG--
extra : rebase_source : 35bf6673cc0acd9d4e6e1a58c573749689614d43
Decoders uses 64-bit values to count frames, so we should use the same type
in FrameStatistics.
Because VideoPlaybackQuality can only use 32 bits (as defined in W3C specs),
we need to ensure that imported FrameStatistics numbers can fit in 32 bits,
while keeping their ratios the same.
MozReview-Commit-ID: 3pUTGK0ekGv
--HG--
extra : rebase_source : 627fada111b51b8830fd38bf6d60a79b899ce603
Move FrameStatistics' data into separate struct, so that it can more easily be
changed and passed around, outside of the lock-controlled FrameStatistics
object.
MozReview-Commit-ID: TfsMRJhVfQ
--HG--
extra : rebase_source : 8c4c6a23c8c2d6ff4272f9f918c9510326691148
VideoPlaybackQuality was fed uint64_t's, now it should be given uint32_t's.
Note that FrameStatistics currently provide uint32_t's, so we are fine now;
nevertheless I added a static_assert to verify that and ensure it stays true.
MozReview-Commit-ID: I0dgP1K4lg3
--HG--
extra : rebase_source : f8d673db0cd45d2b3ae03c092dff217e5d7ebbee
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
When navigating away from a document, we mute the playing media elements
through the NotifyOwnerDocumentActivityChanged() notification.
Sometimes, that function may notify the audio channel agent through its
call to AddRemoveSelfReference() which may call
UpdateAudioChannelPlayingState() and notify the agent, but when we're
navigating away from the page, playingThroughTheAudioChannel will always
be equal to mPlayingThroughTheAudioChannel, which causes us to not
notify the audio channel agent.
This patch fixes this by separating NotifyOwnerDocumentActivityChanged()
from its internal consumers, and forcefully notifying the audio channel
agent when we navigate away.
When navigating away from a document, we mute the playing media elements
through the NotifyOwnerDocumentActivityChanged() notification.
Sometimes, that function may notify the audio channel agent through its
call to AddRemoveSelfReference() which may call
UpdateAudioChannelPlayingState() and notify the agent, but when we're
navigating away from the page, playingThroughTheAudioChannel will always
be equal to mPlayingThroughTheAudioChannel, which causes us to not
notify the audio channel agent.
This patch fixes this by separating NotifyOwnerDocumentActivityChanged()
from its internal consumers, and forcefully notifying the audio channel
agent when we navigate away.
