Dispatching the `MediaDataEncoder::Encode()` invocation is not really
necessary because the callback is desinated to run in task queue anyway.
Also make `Shutdown()` wait for completion to make sure resource is
released before next allocation.
Differential Revision: https://phabricator.services.mozilla.com/D97027
The WMFDecoderModule now uses a crash guard around the loading of the VP9/VP8 MFT. We don't want to always assume that we have a VPx decoder in the GPU process in particular, as it will only be true if a HW decoder is available.
Differential Revision: https://phabricator.services.mozilla.com/D100309
Not the most elegant, but reworking the PDMFactory to be fully re-initialized would be a significant change, as only the WMFDecoderModule requires it we take some shortcuts.
Differential Revision: https://phabricator.services.mozilla.com/D100308
gfxVars::CanUseHardwareVideoDecoding is often set after the first use of the PDMFactory; in this case this would disable HW VP9 decoding for the entire session of the browser.
This value will always end up being true on macOS, so ignore its value in the static Init method.
Differential Revision: https://phabricator.services.mozilla.com/D100307
Upon starting the RDD and GPU process; we check their decoding capabilities and send it to the parent process. It will then broadcast this information to all content children so that RemodeDecoderModule::Supports can return if a codec is supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D100306
When calling PDM::SupportsMimeType not enough information is provided for the PDM to categorically state that a codec isn't supported.
Only creating the decoder successfully matters and the PDMFactory only uses the value returned by Support as a hint to further query the PDM.
Without this change WMFDecoderModule::SupportsMimeType in the GPU process would always return false as it doesn't know yet the KnownCompositor.
Differential Revision: https://phabricator.services.mozilla.com/D100305
We can launch the RDD process early now that it is a fully asynchronous process and doesn't block anything.
This will allow to retrieve the decoding capabilities of the RDD process right away.
Calling this method will actually be handled in bug 1684991 once blockers are sorted (tests and sandbox)
Differential Revision: https://phabricator.services.mozilla.com/D100304
When enabling our MediaTrack implementation (which we don't plan to by default,
NB) and disabling all audio tracks and unselecting all video tracks while having
an active captureStream leads to having no output tracks in DecodedStream.
In this case, DecodedStream doesn't know which graph to use for creating the
intermediary tracks it feeds data to. We don't want to resort to the default
graph either, since two graphs on different clocks could then race each other.
With this patch we plumb down a SharedDummyTrack from the media element where
the captureStream was triggered, through MediaDecoder, to DecodedStream. The
SharedDummyTrack guarantees to keep the graph alive, and holds the graph used
for the output tracks.
Differential Revision: https://phabricator.services.mozilla.com/D99822
The WMFDecoderModule now uses a crash guard around the loading of the VP9/VP8 MFT. We don't want to always assume that we have a VPx decoder in the GPU process in particular, as it will only be true if a HW decoder is available.
Differential Revision: https://phabricator.services.mozilla.com/D100309
Not the most elegant, but reworking the PDMFactory to be fully re-initialized would be a significant change, as only the WMFDecoderModule requires it we take some shortcuts.
Differential Revision: https://phabricator.services.mozilla.com/D100308
gfxVars::CanUseHardwareVideoDecoding is often set after the first use of the PDMFactory; in this case this would disable HW VP9 decoding for the entire session of the browser.
This value will always end up being true on macOS, so ignore its value in the static Init method.
Differential Revision: https://phabricator.services.mozilla.com/D100307
Upon starting the RDD and GPU process; we check their decoding capabilities and send it to the parent process. It will then broadcast this information to all content children so that RemodeDecoderModule::Supports can return if a codec is supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D100306
When calling PDM::SupportsMimeType not enough information is provided for the PDM to categorically state that a codec isn't supported.
Only creating the decoder successfully matters and the PDMFactory only uses the value returned by Support as a hint to further query the PDM.
Without this change WMFDecoderModule::SupportsMimeType in the GPU process would always return false as it doesn't know yet the KnownCompositor.
Differential Revision: https://phabricator.services.mozilla.com/D100305
We can launch the RDD process early now that it is a fully asynchronous process and doesn't block anything.
This will allow to retrieve the decoding capabilities of the RDD process right away.
Ideally, we should have been able to start the RDD process at the same time as the GPU process; however setting up the RDD sandbox is dependent of having mozilla::SandboxBroker::GeckoDependentInitialize() called first ; and it is called in the most awkward of places; so finding a place suitable for all platforms gets affected.
For now we will ensure it's been started around the time the first content process is started.
Differential Revision: https://phabricator.services.mozilla.com/D100304
If multiple audible tabs play at the same time, we call it as `Audio Competition`.
When the audio competition happens, there are several possibilities
(1) ignore that and keep multiple tabs playing at the same time
(2) user manually handles that by pausing or muting audible playing tabs, remaining only an audible playing tab
(3) user enables audio focus management, so gecko would pause them and only allow one audible tab playing at a time
By collecting these situations, we can know the details of how user would react for the audio compeition.
In addition, we also collect the situation where no audio competition happens, in order to know whether the audio competition is common to users.
Differential Revision: https://phabricator.services.mozilla.com/D100292
Previous behavior was to allow requests if the user has ever interacted with
the window. This patch changes from sticky activation to transient
activation.
WindowContext is used rather than Document for the
HasValidTransientUserGestureActivation() test because user activation is a
property of the Window/global.
The error reported when WindowContext is null is the same as that for missing
transient activation, which is keeping the existing behavior.
https://searchfox.org/mozilla-central/rev/66547980e8e8ca583473c74f207cae5bac1ed541/dom/base/Document.cpp#15806
i.e. a missing WindowContext is still treated as missing transient activation.
Differential Revision: https://phabricator.services.mozilla.com/D98275
When we shutdown `MediaSourceDecoder`, it would trigger a shutdown for `MDSM` and a detaching for media source.
In the previous one, that would eventually shutdown `MediaFormatReader` via tasks going through different threads (main->MDSM->MFR's supervisor).
In the latter one, it would eventually detach the `TrackBufferManager` from the `MediaSourceTrackDemuxer`. (main->Demuxer's supervisor)
As these two tasks running in different threads, and the latter usually get finished before the former one, which would result in `MediaSourceTrackDemuxer` no longer being able to get a sample.
When that happens, the reader hasn't been shutdown yet, so it's still holding track demuxers and keeps requesting data from them. Then demuxers would return error because their corresponding track managers have been detached.
The reader would report the demuxing error to the console, but that's acutally not a fatal error, because in this situation the reader is going to be shutdown soon. Therefore, return `NS_ERROR_DOM_MEDIA_CANCELED` to allow MFR to treat this error differently.
Differential Revision: https://phabricator.services.mozilla.com/D100153
Call `waitUntilDisplayedPlaybackChanged()` first to ensure that we won't miss the event. In addition, add more logs in order to help diagnosing issue if timeout happens again.
Differential Revision: https://phabricator.services.mozilla.com/D100277
As now the lowest version SDK we use for developing would be 10.12, so we don't need to this wrapper anymore and can import `MediaPlayer` directly.
Differential Revision: https://phabricator.services.mozilla.com/D97223
RemoteDecoderManagerChild has a number of functions that may be called
asynchronously. Many such functions assert that they can get the manager thread
and that they are on that thread. However, if we've already shutdown, the thread
they fetch will be null. Since we can enter shutdown while async executions of
these functions are pending, we may fail our asserts.
To avoid this, we instead check if the manager thread is null in these
functions, if so, we assume we're in shutdown and bail. If the thread is not
null, we continue as before and assert we are running on the thread as expected.
Differential Revision: https://phabricator.services.mozilla.com/D99824
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Passing a union here allows us to reuse code and trim some code which was
duplicated to handle the different NodeId formats. This also consolidates the
former `NodeId` and `NodeIdData` structures into a new structure (working name
`NodeIdParts`) which represents parts that will later be converted to a string
based NodeId.
Differential Revision: https://phabricator.services.mozilla.com/D93569
This patch implements the transparency support for AVIF image files.
To convert the decoded YCbCr and Alpha data to RGBA, a function named
`ConvertYCbCrAToARGB` is created to do this job in the following
procedure:
ConvertYCbCrAToARGB:
If the layout of the YCbCr is I420
Calling libyuv::I420AlphaToARGB
Else
Fill RGB data converted by ConvertYCbCrToRGB in ARGB buffer first
Insert the alpha data to ARGB buffer
On the other hand, this patch refactors the nsAVIFDecoder a bit to make
the lifetime of the parsed data and decoded image data clearer. They
won't live longer than Parser object and {Dav1d, AOM}Decoder object.
This should improve the code readability.
This patch also adds a transparent image test (TransparentAVIFTestCase)
to check the FLAG_HAS_TRANSPARENCY is posted or not. The test image file
`transparent.avif` is from Bug 1654462.
Differential Revision: https://phabricator.services.mozilla.com/D98951
In D98829, we change the condition of activating a controller, so we have to modify this test as well because now the controller doesn't guarantee it's already audible when gets activated.
Differential Revision: https://phabricator.services.mozilla.com/D99722
John Lin
Michael Froman
Andreas Pehrson
Kartik Gautam
Sylvestre Ledru
Daniel Holbert
Paul Adenot
Jean-Yves Avenard
Byron Campen [:bwc]
Oleg Skoromnik
Mihai Alexandru Michis
Cosmin Sabou
Nico Grunbaum
alwu
Karl Tomlinson
Bryce Seager van Dyk
Alexis Beingessner
Simon Giesecke
Masatoshi Kimura
Csoregi Natalia
Chun-Min Chang