The `VideoDecoder` interface, associated with a `MediaDataDecoder`, is
going to be introduced in Bug 1749045, which can be run on either the
main thread or the worker thread, in the content process.
While the `VideoDecoder` that `RemoteMediaDataDecoder` is associated
with can run on the worker thread, the thread where
`RemoteMediaDataDecoder` runs on, hosted by `RemoteDecoderManagerChild`,
is created and released on the main thread only. Without extra
carefulness, it's easy to have some racing issues in the code with these
complex thread arrangements. It's even harder to figure out the causes
of the issues without clear logs. Adding more RDD logs can be helpful to
debug, especially when rr-recording couldn't capture some
timing-critical intermittent racing issues.
Differential Revision: https://phabricator.services.mozilla.com/D174147
This flag is not supported by most event targets and can have unexpected
side effects (namely spinning a nested event loop). All consumers have
been replaced with a new function which is more explicit about this side
effect.
Differential Revision: https://phabricator.services.mozilla.com/D173985
Scheduling a runnable on a thread from a threadpool is not something one
should ever do, it is bound to fail because the runnable won't run until
the thread is being shut down.
Differential Revision: https://phabricator.services.mozilla.com/D159575
When the media engine id is provided, that means we want to play media
via the media engine, so we don't need to check other remote decoder
modules which don't contain the media engine.
In addition, in D154707, we already check the media engine Id for other
decoder modules, now we no longer need to hack the track support
informtaion for the GPU process due to those checkings and the new
checking we add in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D155031
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
We determine if a type is supported by checking the support information sent from remote processes.
If we haven't received that infermation, what we did before is, simply guess the remote process supports that type, and then try to create a real decoder in the remote process if possible.
However, as now we restrict certain processes can only support certain tracks. We can do that check earlier to eliminate an impossible case. Eg. requesting a video decoder to a process which only supports audio decoding.
Differential Revision: https://phabricator.services.mozilla.com/D155747
When we use the media engine, we have to use the media engine decoder
for both audio and video in order to let media engine manage a/v sync.
This patch fixes the issue of assigning the wrong location for
RemoteAudioChild which causes using wrong audio decoder in the utility
process, instead of the media engine audio decoder.
Depends on D152251
Differential Revision: https://phabricator.services.mozilla.com/D152838
This helps increase the flexibility of extending more remote types
because we will extend the amount of remote processes which we use for
decoding.
Differential Revision: https://phabricator.services.mozilla.com/D153563
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