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
An interesting intermittent condition not previously handled.
We were incorrectly assuming that we always had a decode promise pending when a drain was requested.
If a change of content occurred when resuming from a waiting for data condition: we would have stalled forever as the waiting promise would never have been resolved even after new data was appended.
MozReview-Commit-ID: BQSRSHYqTSe
--HG--
extra : rebase_source : e091969ce35728cd3ded40161eaaa117df2c6886
https://hg.mozilla.org/mozilla-central/file/34c6c2f302e7b48e3ad2cec575cbd34d423a9d32/dom/media/MediaFormatReader.cpp#l2835
NotifyDataArrived() is dispatched again if |mNotifyDataArrivedPromise.Exists()| which will then be dispatched again
recursively until mNotifyDataArrivedPromise is completed. This is a waste of CPU cycles.
We can use a dirty flag to note we should update buffer ranges again when the current update is done.
MozReview-Commit-ID: 6hInhGKnXJE
--HG--
extra : rebase_source : 71aa2c16112428c34def094515e37aa1f028a3fc
An interesting intermittent condition not previously handled.
We were incorrectly assuming that we always had a decode promise pending when a drain was requested.
If a change of content occurred when resuming from a waiting for data condition: we would have stalled forever as the waiting promise would never have been resolved even after new data was appended.
MozReview-Commit-ID: BQSRSHYqTSe
--HG--
extra : rebase_source : a608377b935427faa7cd8042d0226e64e86e17b9
Nicholas Nethercote
Gerald Squelart
Kilik Kuo
Csoregi Natalia
Jean-Yves Avenard
Sebastian Hengst
Kaku Kuo
JW Wang
Iris Hsiao
Wes Kocher