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
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
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
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
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
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
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
The concept of ImageRect only exists with the WebM container. It defines a rectangle that will be used to crop the decoded image.
Initially (and as still indicated in the comment for VideoInfo.mImageRect) that field was only ever initialised by the WebMDemuxer.
So we now make this an optional value that needs to be explicitly initialised to be active, and only do so in the WebMDemuxer.
Differential Revision: https://phabricator.services.mozilla.com/D99601
This moves parts of IPCMessageUtils.h to two new header files and adapts
the include directives as necessary. The new header files are:
- EnumSerializer.h, which defines the templates for enum serializers
- IPCMessageUtilsSpecializations.h, which defines template specializations
of ParamTraits with extra dependencies (building upon both IPCMessageUtils.h
and EnumSerializer.h)
This should minimize the dependencies pulled in by every consumer of
IPCMessageUtils.h
Differential Revision: https://phabricator.services.mozilla.com/D94459
The RDD process startup being asynchronous make the operation trivial. Unlike with the GPU process, we can immediately tell the MediaFormatDecoder that a new decoder is needed when the RDD died.
Recovery will immediately occur with little visible interruption.
Differential Revision: https://phabricator.services.mozilla.com/D98571
Now that launching the RDD process is fully asynchronous and no longer block the parent main thread, we can enable it on all platforms.
If we did fail to start it, we will not attempt again unless on Nightly.
Re-enable the RDD on Windows for ARM seeing that even if it did fail, it won't inconvenience the user anymore (other than the first video/audio element will take longer than usual to start)
Differential Revision: https://phabricator.services.mozilla.com/D96669
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
With a GPU remote decoder, the rejection code will only run once the GPU process has been been restarted. It is possible that once this happens, that Shutdown has been called before which would have rejected any pending promise.
Differential Revision: https://phabricator.services.mozilla.com/D96757
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
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
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
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
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
The code always assumed that the size of the image with the Y plane dimensions, which, while often the case, isn't correct.
We remove the assertions that the display offset was always (0,0) and properly carry the actual data over IPC.
Remoting the theora decoder and enabling fast video copy exposed several other related issues in the various D3D11 image types.
Various WPT uses theora YUV44 images (because we do not support YUV444 H264 ones). Those images are made of 32 pixels planes with a display size set to 20 pixels. Prior P1D the backend image was a ShareYCbCrPlanar image which correctly handled the size settings.
Like the image serializer, the various D3D11 images always assumed that the Y plane size was the image size.
This however expose existing issues where the offset position of the display is completely ignored for some image type. See bug 1669054
All those problems explain why sometimes we displayed more pixels than we should have.
Depends on D91914
Differential Revision: https://phabricator.services.mozilla.com/D92233
Jean-Yves Avenard
Mihai Alexandru Michis
Bryce Seager van Dyk
Simon Giesecke
Sylvestre Ledru
Matt Woodrow
Cristina Coroiu
Dorel Luca
Bogdan Tara
Ricky Stewart