This patch moves the media engine from the RDD process to the new
utility process, and create video bridge between the new utility process
and the GPU process in order to share the texture.
Differential Revision: https://phabricator.services.mozilla.com/D155901
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
Create a media engine that would be responsible to play media. We would perform any commands sent from the content process on the media engine, and also notify the content process when the media engine updates its status, notifying some useful events, or encountering any error.
Differential Revision: https://phabricator.services.mozilla.com/D144634
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
Create a media engine that would be responsible to play media. We would perform any commands sent from the content process on the media engine, and also notify the content process when the media engine updates its status, notifying some useful events, or encountering any error.
Differential Revision: https://phabricator.services.mozilla.com/D144634
Create a media engine that would be responsible to play media. We would perform any commands sent from the content process on the media engine, and also notify the content process when the media engine updates its status, notifying some useful events, or encountering any error.
Differential Revision: https://phabricator.services.mozilla.com/D144634
Create a media engine that would be responsible to play media. We would perform any commands sent from the content process on the media engine, and also notify the content process when the media engine updates its status, notifying some useful events, or encountering any error.
Differential Revision: https://phabricator.services.mozilla.com/D144634
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
In future parts, TaskQueue will require extra initialization to be performed
which cannot happen in a constructor, as it takes references to the TaskQueue
object itself, which will require the introduction of a helper method. This
patch switches all callers of the TaskQueue constructor to use the new method.
Differential Revision: https://phabricator.services.mozilla.com/D142604
While running SandboxTest on Windows/Debug setup we can encounter a GPU
process hanging at shutdown. This is due to a destruction race between
GPUParent and VideoBridgeParent, and we end up with one
CompositorThreadHolder reference that is not properly released, making
the GPU process waiting for it.
This change aims at doing the release earlier to prevent such a
destruction race.
Differential Revision: https://phabricator.services.mozilla.com/D121045
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
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
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
This renames the thread and identifiers derived from the thread's name. This is
to avoid ambiguity over if the thread relates to the MediaController class,
which it does not.
Differential Revision: https://phabricator.services.mozilla.com/D93806
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
We unfortunately can't use the AsyncShutdownService in either the GPU or RDD process.
So we add a little utility class AsyncBlockers that will resolve its promise once all services have deregistered from it.
We use it to temporily suspend the RDDParent or GPUParent from killing the process, up to 10s.
This allows for cleaner shutdown as the parent process doesn't guarantee the order in which processes are killed (even though it should).
Differential Revision: https://phabricator.services.mozilla.com/D90487
We unfortunately can't use the AsyncShutdownService in either the GPU or RDD process.
So we add a little utility class AsyncBlockers that will resolve its promise once all services have deregistered from it.
We use it to temporily suspend the RDDParent or GPUParent from killing the process, up to 10s.
This allows for cleaner shutdown as the parent process doesn't guarantee the order in which processes are killed (even though it should).
Differential Revision: https://phabricator.services.mozilla.com/D90487
Historically, the MediaThreadType::PLAYBACK was used just for that; the MediaDecoderReader and exclusively for playback content.
This is no longer the case ; it's used in multiple places, and not just with playback: webrtc, webaudio, benchmark etc.
The primary use of the "PLAYBACK" thread was to distinguish from the "PLATFORM_DECODER" one as they dispatch synchronous tasks from one to the other, and we must ensure they don't share the same threadpool.
CONTROLLER is more fitting here, as this is how it's typically used: a controller thread manage the decoder threads.
Additionally, we remove the MTG_CONTROL one as it's not used.
Differential Revision: https://phabricator.services.mozilla.com/D85543
Sync dispatch are being used; due to how the background taskqueue is setup this could cause a hang if if also called from a background taskqueue.
Differential Revision: https://phabricator.services.mozilla.com/D82500
Sync dispatch are being used; due to how the background taskqueue is setup this could cause a hang if if also called from a background taskqueue.
Differential Revision: https://phabricator.services.mozilla.com/D82500
Sync dispatch are being used; due to how the background taskqueue is setup this could cause a hang if if also called from a background taskqueue.
Differential Revision: https://phabricator.services.mozilla.com/D82500
