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
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--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
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 of implementation. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by 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
Continuing on the infrastructure provided by bug 1363668 we will now forcibly disable hardware decoding if the first frame failed to decode with a hardware accelerated decoder.
Depends on D7615
Differential Revision: https://phabricator.services.mozilla.com/D7616
--HG--
extra : moz-landing-system : lando
Also fix a long-term data race where we could read and write on mInfo.{mVideo,mAudio} on different task queues.
Differential Revision: https://phabricator.services.mozilla.com/D7484
--HG--
extra : moz-landing-system : lando
If the content being played was first non-encrypted, the PDMFactory would have been set without a CDMProxy. As such, it is necessary to use a new PDMFactory when the encryption type changes (from clear to encrypted).
Rather than attempting to detect if the encryption status has changed, simply use two PDMFactory, one with CDMProxy set and one without (for clear content)
Also, never attempt to recycle a decoder if the encryption type changed (used only on Android)
The TrackBuffersManager would have already handle the dispatching of the encrypted event when parsing the new init segment. As such, nothing more is necessary.
MozReview-Commit-ID: Jn14P2F6N5V
--HG--
extra : rebase_source : afe254fa8c4b835b15d9d48bb52d832f28196b7e
Adding some documentation to clarify on the difference between mInfo and mOriginalInfo
MozReview-Commit-ID: DWBsoi16QKf
--HG--
extra : rebase_source : 719c17b9ce61efdb633db108230f1bf78773ee51
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
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
The WaitForDataPromise cannot be resolved even when key has been updated and decode request has be resolved.
2 ScheduleUpdate(NotifyTrackDemuxer, NotifyNewOutput) are merged into 1 so that only mReceivedNewData is set to false again but MFR will
never have a chance to trigger another Update to call CancelWaitingForKey.
By refactoring the condition to resolve the WaitForDataPromise, MDSM is able to request new data and MFR is able to cancel waitingforkey then continue the flow.
MozReview-Commit-ID: 31brwzOoUvF
--HG--
extra : rebase_source : 8caf8b426dd693e2806ebb8a059a3b91026d7f52
We unfortunately can't store this information in the VideoInfo as typically the framerate isn't found in the container's metadata. Additionally, the VideoInfo object is readable-only as it is shared across threads.
As such, we can only estimate it as we demux samples.
MozReview-Commit-ID: 5HB33ubfGAs
--HG--
extra : rebase_source : 1d6d09da76a99524422b14d50db477a9aa222da0
This will allow to modify the string returned later.
MozReview-Commit-ID: Giw1JyukE4v
--HG--
extra : rebase_source : d126b8b956ff1f54c33a838834aee9cc6340de95
This will allow to modify the string returned later.
MozReview-Commit-ID: Giw1JyukE4v
--HG--
extra : rebase_source : d126b8b956ff1f54c33a838834aee9cc6340de95
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
So we can remove the use of AbstractMediaDecoder::NotifyDecodedFrames().
MozReview-Commit-ID: Ch7Saha6zdi
--HG--
extra : rebase_source : 8562faa56d1f31797643ed0f7ae550765d8c86d7
extra : intermediate-source : 05b50517cc40f2adf06facfccea628488dd319da
extra : source : d5af89f5a09e03c8fbb0d6111f88e3221f3a1d57
We will remove MediaDecoderReader in the future.
MozReview-Commit-ID: BaCRXleKK5a
--HG--
extra : rebase_source : dc14a593d6291136f02b1deb910cd6dcd01c0355
extra : source : 8f71b7dae0a541562c7c3829b5a873e9f9fd2674
It would be handy we want to pass more data to the constructor.
MozReview-Commit-ID: 3AUUsTbv534
--HG--
extra : rebase_source : 8d230c85addf1ba296e6a0512f0d18ebd41c0d17
extra : source : e6568e9fa24f52c59baecaa16aa044b492f407fb
It is not used.
MozReview-Commit-ID: EDPhN6RzKN0
--HG--
extra : rebase_source : ab743da08760cd4014504528581d935ea9aa6752
extra : source : 3a7f3b90239b4bdf96c25e5df2f0c49a6c326c42
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
The MediaFormatReader now takes the MediaResult from the Demuxer::Init promise
resolution, and if there are no other errors but the MediaResult is not NS_OK
it will forward that warning to the decoder owner (i.e., the associated
HTMLMediaElement).
MozReview-Commit-ID: 5rTmzqqPLI0
--HG--
extra : rebase_source : 5f81db185a01c012bf0418af2a42986db14a7e6f
Nicholas Nethercote
Tarek Ziadé
shindli
Jean-Yves Avenard
Ehsan Akhgari
Bryce Van Dyk
Cosmin Sabou
Sylvestre Ledru
Dorel Luca
Gerald Squelart
Kilik Kuo
Csoregi Natalia
Sebastian Hengst
Kaku Kuo
JW Wang