On MinGW, it lacks of the headers for RunTimeClass and we have trouble to make it work. This patch adds a new config for Media Engine in order not to build related files on MinGW environment.
In addition, MinGW build version of Firefox is only used for Tor browser and it's ok to disable this feature for them for now. If they want to port this feature in the future as well, then we can see if we can fix the build problems at that time.
Differential Revision: https://phabricator.services.mozilla.com/D150660
On MinGW, it lacks of the headers for RunTimeClass and we have trouble to make it work. This patch adds a new config for Media Engine in order not to build related files on MinGW environment.
In addition, MinGW build version of Firefox is only used for Tor browser and it's ok to disable this feature for them for now. If they want to port this feature in the future as well, then we can see if we can fix the build problems at that time.
Differential Revision: https://phabricator.services.mozilla.com/D150660
This patch implements a new IPDL which is used for communicating with the remote media engine. It will be used between the content process and the RDD process.
For each media engine pair, they would share an unique ID, which is used to indentify different engine pairs (if any) and for querying a specific engine via Id, which is implemented in the next patch.
Depends on D140014
Differential Revision: https://phabricator.services.mozilla.com/D139204
This patch implements a new IPDL which is used for communicating with the remote media engine. It will be used between the content process and the RDD process.
For each media engine pair, they would share an unique ID, which is used to indentify different engine pairs (if any) and for querying a specific engine via Id, which is implemented in the next patch.
Depends on D140014
Differential Revision: https://phabricator.services.mozilla.com/D139204
This can fail if PBackground has been shut down, while the message was queued between threads.
It happens sometimes during xpcshell tests, and disabling OMTP makes it more common (but is unrelated, just changes timings).
The actual LaunchRDDProcessIfNeeded code also gracefully handles this failure mode, so not asserting shouldn't be a problem.
Depends on D106053
Differential Revision: https://phabricator.services.mozilla.com/D106824
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
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
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
We can now chaincreation of the decoder to the launch of the RDD process as needed and setting up the PRemoteDecoderManager
Differential Revision: https://phabricator.services.mozilla.com/D96365
PDMFactory::CreateDecoder is changed to return a MozPromise that will contain the MediaDataDecoder once created.
This will allow to later make RemoteDecoderManager fully asynchronous and no longer require an IPC sync call to start the RDD process.
We also modify the WebrtcMediaDataDecoderCodec to never create a decoder on the main thread, which could cause deadlocks under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D96364
There's no longer have a GpuDecoderModule and RemoteGpuDecoder.
So we no longer need the IRemoteDecoderChild abstraction layer.
Differential Revision: https://phabricator.services.mozilla.com/D96359
We can now chaincreation of the decoder to the launch of the RDD process as needed and setting up the PRemoteDecoderManager
Differential Revision: https://phabricator.services.mozilla.com/D96365
PDMFactory::CreateDecoder is changed to return a MozPromise that will contain the MediaDataDecoder once created.
This will allow to later make RemoteDecoderManager fully asynchronous and no longer require an IPC sync call to start the RDD process.
We also modify the WebrtcMediaDataDecoderCodec to never create a decoder on the main thread, which could cause deadlocks under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D96364
There's no longer have a GpuDecoderModule and RemoteGpuDecoder.
So we no longer need the IRemoteDecoderChild abstraction layer.
Differential Revision: https://phabricator.services.mozilla.com/D96359
In bug 1595994 we attempted to streamline the ability to determine which decoder was available regardless of the process they would be running in. This was subsequently done via the PDMFactory.
As there are several JS API that can query which codec are supported, it requires a synchronous mechanism.
This allowed to make a determination during the PlatformDecoderModule::Supports call, depending on which process it was going to be called frome.
Having a synchronous IPC call to the RemoteDecoderManagerParent has too many caveats to be workable.
So what we do instead is first determine at launch if the required external framework are available and pass this information to each content process.
When checking if a decoder is available, we make a best guess at determining if the PDM would support such codec, without actually loading such framework when running in the content process.
Supports can no longer make a decision based on the process currently running and as such PDM::CreateAudio/VideoDecoder using an optional system framework now need to further check the validity of the CreateDecoderParam argument.
Differential Revision: https://phabricator.services.mozilla.com/D95245
And we remove unnecessary checks, BackgroundParent only run in the parent process and if e10s is on. Also RecvLauchRDDProcess will only ever be called if the rdd pref is on already.
By streamlining the call we also reduce the number of sync dispatch to 1.
Depends on D93317
Differential Revision: https://phabricator.services.mozilla.com/D93476
Add a synchronous Supports message to the IPDL PRemoteDecoderManager protocol so
decoder modules can query for playback support in the actual process that will
attempt to do the decoding.
Depends on D54878
Differential Revision: https://phabricator.services.mozilla.com/D54879
