Create a new namespace `MediaControlService` to use those helper functions which is used to get the main controller related status.
Then, move those functions from `ChromeUtils` to `MediaControlService`, which give us two benefit. The first is that we can remove redudant test-only enum `MediaSessionPlaybackTestState`, the second is a pref-required work for bug1656398, to fix the build order error when exposing `MediaSessionPlaybackState` in the media controller's webidl.
Differential Revision: https://phabricator.services.mozilla.com/D86620
When document's title is empty, we would use the default title as well in order to prevent showing nothing on the virtual control interface.
Differential Revision: https://phabricator.services.mozilla.com/D86246
Implement `ForceToBecomeMainControllerIfNeeded()` to refine the process of activating controller and requesting to become a main controller.
Differential Revision: https://phabricator.services.mozilla.com/D85518
Rename `NotifyControllerBeingUsedInPictureInPictureMode()` to `RequestUpdateMainController()` and call that method when a controller enters fullscreen.
Differential Revision: https://phabricator.services.mozilla.com/D85517
Treat media controller being used in fullscreen as same as the one being used in PIP mode, so it won't be replaced by other normal controller if it's already a main controller.
Comparing with a normal controller, a controller being used in PIP/fullscreen should have a higher priority to become a main controller.
In addition, renaming `IsMediaBeingUsedInPIPModeOrFullScreen()` to `IsBeingUsedInPIPModeOrFullscreen()`.
Differential Revision: https://phabricator.services.mozilla.com/D85514
The MediaChangeMonitor would always use the selected PDM in order to create a decoder; this only worked if the Decode method returned an error if the format was unsupported and this is how the WMF decoder worked.
However, the AppleVTDecoder fails on creation instead.
Now that the VP9 profile is known at creation time, we should move the WMF decoder to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D86545
To create a VP9 decoder, the VideoToolbox requires a vppC atom similar to how the H264 one requires an avcC one.
That information is typically not available in the webm container and is found in the VP9 bytestream with each keyframe.
In order to minimise the extent of the changes, we move the task of retrieving the vpcC content in the MediaChangeMonitor as it already performs a similar task in order to detect if the format has changed.
The VPXChangeMonitor will now only instantiate a VP9 decoder once a keyframe is seen.
Differential Revision: https://phabricator.services.mozilla.com/D86544
This is a partial revert of "Bug 1650996 - P3. Have RemoteDecoderManagerChild use a TaskQueue over a media threadpool."
The RemoteDecoderManagerChild dispatch tasks synchronously, right now it is doing so on the media controller's thread pool ; however in the following patch it will change the creation to the decoder's thread pool.
If we attempt to instantiate too many decoders at once, we run out of available threads and dead-lock in the sync dispatch.
This issue has bitten us in various places already and the solution was always assuming that the decoder will always be created on the controller's thread and used on the decoder's thread.
This assumption won't hold any longer and was difficult to keep anyway.
So we have the RemoteDecoderManagerChild uses a dedicated thread so that we can guarantee there will always be an available thread to create the decoder.
Depends on D86543
Differential Revision: https://phabricator.services.mozilla.com/D86895
The mac VP9 decoder; like the H264 requires some out of band settings before it can be created.
This information is only found in the mp4 container, we can create it from the vp9 bitstream.
For now we ignore the colors information as we can't handle it properly yet in our compositor and this is not available in the bytestream.
Differential Revision: https://phabricator.services.mozilla.com/D86542
This adds the current browserId to the internal stats report. The peer
connections are sorted by browserId, and a "Show tab" button is added that will
select the tab associated with the peer connection to make it easier to keep
track of which peerconnection is associated with a tab.
Differential Revision: https://phabricator.services.mozilla.com/D86699
The MediaChangeMonitor would always use the selected PDM in order to create a decoder; this only worked if the Decode method returned an error if the format was unsupported and this is how the WMF decoder worked.
However, the AppleVTDecoder fails on creation instead.
Now that the VP9 profile is known at creation time, we should move the WMF decoder to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D86545
To create a VP9 decoder, the VideoToolbox requires a vppC atom similar to how the H264 one requires an avcC one.
That information is typically not available in the webm container and is found in the VP9 bytestream with each keyframe.
In order to minimise the extent of the changes, we move the task of retrieving the vpcC content in the MediaChangeMonitor as it already performs a similar task in order to detect if the format has changed.
The VPXChangeMonitor will now only instantiate a VP9 decoder once a keyframe is seen.
Differential Revision: https://phabricator.services.mozilla.com/D86544
The mac VP9 decoder; like the H264 requires some out of band settings before it can be created.
This information is only found in the mp4 container, we can create it from the vp9 bitstream.
For now we ignore the colors information as we can't handle it properly yet in our compositor and this is not available in the bytestream.
Differential Revision: https://phabricator.services.mozilla.com/D86542
The window opened by the crashtests does not show up in the list
maintained by BrowserWindowTracker, so we never end up with any tabs to
share, causing the test to hang. I don't like to remove a test, but this
was written for the old version of tab sharing which has been completely
removed, and there doesn't seem to be a clear path ahead which would
make this test pass without adding special case code in tab sharing that
would work with crashtests.
Depends on D84593
Differential Revision: https://phabricator.services.mozilla.com/D86564
A lot of tests assume that the screen will be the last thing enumerated.
It is also the "scariest" option, so having it last makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D84593
A lot of tests assume that the screen will be the last thing enumerated.
It is also the "scariest" option, so having it last makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D84593
VAAPI HW surfaces are released at ReleaseUnusedVAAPIFrames() and we use DMABufSurface::IsUsed() flag
to detect unused surfaces. Then we call GetUnusedDMABufSurfaceWrapper() to get unused surfaces to
re-use them for decoding.
Because DMABufSurface::IsUsed() flag is updated asynchronously it may change
between ReleaseUnusedVAAPIFrames() and GetUnusedDMABufSurfaceWrapper() calls.
In that case GetUnusedDMABufSurfaceWrapper() may return unused but also unreleased surface
as it was marked as used in time of ReleaseUnusedVAAPIFrames() call.
In this patch explicitly release VAAPI data of any surface before we re-use it.
Also fail when we try to upload data to already used DMABufSurfaceYUV surface.
Differential Revision: https://phabricator.services.mozilla.com/D85842
In bug1654045, we would stop controlling media once media reaches to the end. Considering some user might still want to control media by pressing media keys even if it has ended, so adding a pref to control this abilitiy.
Differential Revision: https://phabricator.services.mozilla.com/D85930
Chun-Min Chang
Mihai Alexandru Michis
Chris Fronk
alwu
Jean-Yves Avenard
Lee Salzman
Dan Minor
Emilio Cobos Álvarez
Bogdan Tara
Csoregi Natalia
Martin Stransky
Noemi Erli
Simon Giesecke
Matt Woodrow
Edgar Chen
Karl Tomlinson