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
We rename a method in FrameStatistics to better match what it's actually doing.
Differential Revision: https://phabricator.services.mozilla.com/D4213
--HG--
extra : moz-landing-system : lando
We rename a method in FrameStatistics to better match what it's actually doing.
Differential Revision: https://phabricator.services.mozilla.com/D4213
--HG--
extra : moz-landing-system : lando
We rename a method in FrameStatistics to better match what it's actually doing.
Differential Revision: https://phabricator.services.mozilla.com/D4213
--HG--
extra : moz-landing-system : lando
We extract the GlobalAllocationPolicy and the MediaDataDecoder wrapper from MediaFormatReader.
They will be used to create a new wrapping class that will serialize allocation and initalization of decoders if the platform requires it.
Differential Revision: https://phabricator.services.mozilla.com/D3676
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
If the particular track isn't encrypted, there's no need to wait for a CDMProxy.
MozReview-Commit-ID: DPbvbwsO58N
--HG--
extra : rebase_source : 0e7fea134404c861268dc8759cd7c0ebdf83dca4
The code couldn't have worked and didn't do what the comment stated. When the CDMProxy changes, the current PDMFactory for encrypted content can no longer be used.
MozReview-Commit-ID: 7LpcQkK5gLL
--HG--
extra : rebase_source : e3926034069285be1559d0a1ea20d5f3c1561eb7
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
Additionally, show the number of channels and the sampling rate.
MozReview-Commit-ID: L067Hbv0bXz
--HG--
extra : rebase_source : 193482c7e96b0094ec4d717a9cc30e371067aa1d
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
The logging added in this patch was landed to help debug very rare shutdown
failures on android, but the logging runs on other platforms and is annoying.
No one is looking at fixing the rare shutdown problem on Android. So remove the
logging until fixing the shutdown failure becomes a priority.
Mostly-mechanical replacement of MOZ_LOG with DDMOZ_LOG, usually just removing
the class name and `this` pointer (as they are already implicitly recorded).
Some files needed a bit more work when logging was done from helper classes or
static functions.
MozReview-Commit-ID: IeJJmzYqWMQ
--HG--
extra : rebase_source : 94200838dcdaf6c3bda9de30042ce2d307237eef
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
Capturing |this| only if |self| needs to appear more than twice in a lambda.
MozReview-Commit-ID: 38iYDznjgBH
--HG--
extra : rebase_source : 9471fd4519c5c5be6e6e10eb11db8eeb041327d1
None of our audio decoders require draining, and as all audio frames are keyframes, we can always resume decoding from where we left of when encountering a gap in the data.
The vorbis decoder always "eats" the first sample provided, causing unecessary seek and drain.
This issue will be addressed in another change.
MozReview-Commit-ID: LNd3Pz4QT4v
--HG--
extra : rebase_source : e9e2763ec8d9e933a88319f5965fc08e154347ae
Use ErrorName() as it provides more useful information for the error detail.
MozReview-Commit-ID: BQUPQGcLd8L
--HG--
extra : rebase_source : 734825c88dfbe79de1e61498dcc24606c50314ee
Print error code couldn't effectively help people understand the reason of error, we should print its name.
MozReview-Commit-ID: KaBTi8zpq91
--HG--
extra : rebase_source : 64eebd9af18fcb5062ff347464045bb9327fb716
We misused MFR::DecoderData's address as an identity in bug 1393399 but our intention was MediaDataDecoder's address.
We report telemetry data when we get the 1st decoded frame from a new MediaDataDecoder, which is identified by its address.
If we misuse the MFR::DecoderData's address as identity, it will take longer than we expect since only when
the MFR is recreated will we get a new MFR::DecoderData.
MozReview-Commit-ID: HOf5hTSoBed
--HG--
extra : rebase_source : 76731bd11eac9243a23a972f85c72203c3a3e7f1
PDMFactory::CreateDecoder may not always modify CreateDecoderParams::mError as not all PDM handle this optional return value.
MozReview-Commit-ID: K8WFA0o778U
--HG--
extra : rebase_source : 55c35ab0cb5282d8dfbd1bbc1a2e6e22d97d3209
We only process a demuxed sample at a time. Waiting until one is decoded to do the next pending ones.
MozReview-Commit-ID: JlXhyPzso8U
--HG--
extra : rebase_source : c11185ca75fd5950aa4273dd9ec03d2cf9b217ba
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
Don't unnecessarily, create a decoder, flush, shutdown and create a new one on the first sample.
MozReview-Commit-ID: 8utEX5JEmq8
--HG--
extra : rebase_source : e40548e7ef4ad1a8e3c57f3070a2ffc77bf81a3f
Jean-Yves Avenard
Csoregi Natalia
Andreea Pavel
Emilio Cobos Álvarez
Nicholas Nethercote
Chris Pearce
JW Wang
Gerald Squelart
John Lin
Brindusan Cristian
Kilik Kuo
Andrea Marchesini
shindli
James Cheng
bechen@mozilla.com
Sebastian Hengst
Alastor Wu
Kaku Kuo