This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
We should always append sample by using `AppendSample()` to assert whether a sample is valid, so making `mSamples` private can prevent a direct usage of the nsTarry's `AppendElement()`.
Also provide a method to return non-const mSamples which is only used for the move semantics.
Differential Revision: https://phabricator.services.mozilla.com/D38427
--HG--
extra : moz-landing-system : lando
Return demux error when we get a invalid sample. For mp4 demuxer, we use `MOZ_DIAGNOSTIC_ASSERT` instead because we are pretty sure that it won't happen.
Differential Revision: https://phabricator.services.mozilla.com/D38553
--HG--
extra : moz-landing-system : lando
We don't want to have a sample with invalid time, duration, end time or end timecode, so add a diagnostic assertion to check. And will handle invalid sample for demuxers in next patch.
Differential Revision: https://phabricator.services.mozilla.com/D38426
--HG--
extra : moz-landing-system : lando
This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
--HG--
extra : rebase_source : 0570540496302b3efedadf4d5115ee5422d5c279
The Java ExoPlayer that we use for HLS support on Android does an accurate
seek, that is, it seeks to the frame at the seek target. This may not be a
keyframe, which we can start decoding at. So change the HLS seek to seek 2
seconds behind the seek target, and drop all frames up to the next keyframe.
This means that after a seek the HLSDemuxer will output a keyframe, and
hopefully (but we can't guarantee of course) it will lie behind the actual seek
target.
We also need to purge the GeckoHlsVideoRenderer's queue of frames which it
is holding onto in order to determine their durations, otherwise after a seek,
we'll get output from this queue of frames. That is, after a seek we would still
get a few frames from the old playback position.
This seek case is particularly problematic as we aggressively shutdown decoders
when the media is paused, including right after the load reaches
loadedmetadata, and we need to seek in order to recover from going dormant.
Differential Revision: https://phabricator.services.mozilla.com/D33254
--HG--
extra : moz-landing-system : lando
Each instance has an instance of Java ExoPlayer that consumes memory in the
limited JVM heap. Too many concurrent players will cause OutOfMemoryError.
Differential Revision: https://phabricator.services.mozilla.com/D20420
--HG--
extra : moz-landing-system : lando
HLSResourceCallbacksSupport::mDecoder is cleared on main thread too, so
the nullness check already ensures decoder methods won't be called after
shut down. In fact, for OnError() the lock is harmful because the task calls
MediaDecoder::NetworkError(), which triggers decoder shutdown and eventually
HLSResourceCallbacksSupport::Detach(), which tries to lock the mutex again
while the mutex is still locked.
Differential Revision: https://phabricator.services.mozilla.com/D16709
--HG--
extra : moz-landing-system : lando
Explicitly store the crypto scheme being used on our crypto structs to let us
differentiate between cenc and cbcs data. In doing so remove mMode and replace
mValid with IsEncrypted() for the following reasons:
- Different modes within the existing schemes are not currently utilized by the
spec: the scheme implies mode. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by the spec --
possibly if the isProtected flag which we were tracking with mMode, is
ever changed to be more than a bool in the spec.
- mValid was typically used to check if these structs contained valid crypto
data or not. With only one scheme this was often shorthand for 'IsEncrypted',
but with multiple schemes what is considered valid data for one may not be for
another. Do away with this and just explicitly have an 'IsEncrypted'.
Differential Revision: https://phabricator.services.mozilla.com/D15874
--HG--
extra : moz-landing-system : lando
Summary:
TaskQueue no longer requires an explicit call to BeginShutdown() as such we no longer have a need for AutoTaskQueue.
Depends on D1621
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1622
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
PinForSeek() is called only when playback reaches the end. In other words,
it is not called for most cases of seeking. It should be OK not to call it at
all during seeking.
MozReview-Commit-ID: 1xXX1321bO7
--HG--
extra : rebase_source : df8ba3f59da2a337b456546af4b54abaddfe38a9
extra : intermediate-source : 0a70419f9ce639ac0784a0632db4598d6be511f8
extra : source : bfddad9b922386c91fcfa7657a7ac274991d15f4
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
Also devirtualize ChannelMediaDecoder::DownloadProgressed() and move it to private.
MozReview-Commit-ID: ITv3ISRbN5t
--HG--
extra : rebase_source : aa75bc11fc1a4af8df15db9224928b1f02267b80
This moves the include into the file where it's used, and means I don't need
to import it into gecko-media crate yet.
MozReview-Commit-ID: JnEgtwnLxgO
--HG--
extra : rebase_source : 84f9b98e3c64dc1a337a12b714fd4c8bc45429a1
extra : source : 396e995935c6ada2a069c56cd1ede3c9ef418f31
The only actual code use in MediaSourceDemuxer can trivially be folded into
its caller GetNumberTracks in the same class.
MozReview-Commit-ID: E6zh98zmJwJ
--HG--
extra : rebase_source : 9358dc37523d6cd7c1a4d5ec62a790db6a092063
When GPU process crashes, the MediaDecoder, MDSM, and MFR are all destroyed.
So, we use MediaDecoderOwner to identify which video we're dealing with.
MozReview-Commit-ID: 1cv08M7Cpcf
--HG--
extra : rebase_source : 62f7be874d97a58eb4c1d7a98b4e9fe83a9313d3
Move the dependent method into HLSDecoder.
Remove the class entirely.
MozReview-Commit-ID: F9eOFQvgeLQ
--HG--
extra : rebase_source : a45407d88513883245f429c5f4bd09c78bef6f10
Sub-classes should know how to pin/unpin the resource.
MozReview-Commit-ID: 50S8oSD5oEU
--HG--
extra : rebase_source : 5e1b7c657b759c0d1dfdd7b5c0a4b7dbc4077ffe
extra : intermediate-source : 3000b76a3b97c08955c2d584ac215114c8e8f59a
extra : source : a56b9846db916ff85a0cae09736c3284bd895506
We will move the implementation to sub-classes which have more details
about how to calculate the resource size.
MozReview-Commit-ID: 7lfiz5GNtPE
--HG--
extra : rebase_source : bf14ef91a6de456d65bee7cb1f53f8e542f55247
extra : source : 22640df9dd3a1491594a82b3d0bd175e46073fa3