The stream order does not depend on streams' finished state, so these calls are
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D47687
--HG--
extra : moz-landing-system : lando
This functionality is not used since we moved to only having a single track per
MediaStream (bug 1493613).
Differential Revision: https://phabricator.services.mozilla.com/D47686
--HG--
extra : moz-landing-system : lando
TrackID has been used to denote tracks that are part of MediaStreams in the
MediaStreamGraph. The TrackInfo::mTrackId IDs are no longer used in the
MediaStream APIs and as such it's not necessary that they have the type TrackID.
This patch changes TrackInfo::mTrackId to be of type uint32_t instead, as that
is the type of Mp4parseTrackInfo::track_id, which is assigned to
TrackInfo::mTrackId as the sole remaining non-static user.
Other users set a static trackId of `1` or `2`, and as such remain supported by
this change.
Differential Revision: https://phabricator.services.mozilla.com/D46763
--HG--
extra : moz-landing-system : lando
By default, the remote process takes ownership of a shmem when it's sent over ipc.
Using "unsafe" shmem allows any processes to read/write/deallocate such shmem.
Differential Revision: https://phabricator.services.mozilla.com/D47554
--HG--
extra : moz-landing-system : lando
In `MediaEngineWebRTCMicrophoneSource::EvaluateSettings`, on default settings, the `prefs.mChannels` is updated accordingly. However, it is not used for the calculation of the `FlattenedConstraints`. As a result, the channel count is 0, which is converted to 1, and not the actual device channel count as it should. Thus, the `prefs.mChannels` is used in the calculation of the `FlattenedConstraints`.
Differential Revision: https://phabricator.services.mozilla.com/D47453
--HG--
extra : moz-landing-system : lando
Now that we have explicit macros for each GMP_LOG level GMP_LOG and
GMP_LOG_DEBUG are doing the same thing. This patch replaces all instances of
GMP_LOG with GMP_LOG_DEBUG. This has the benefit of all uses of the GMP macros
sharing a consistent naming convention and being explicit about the level
they're logging at.
Since we no longer use GMP_LOG() anywhere, remove it.
Differential Revision: https://phabricator.services.mozilla.com/D47374
--HG--
extra : moz-landing-system : lando
I've reworked the includes in most of the files I've touched since I was adding
GMPLog.h:
- Reordered the includes to better match the Google C++ style.
- Removed includes that are already included from the associated header or
GMPLog.h. I.e. if Foo.cpp includes Foo.h, and Foo.cpp includes other headers
already included in Foo.h, these were removed.
Depends on D47194
Differential Revision: https://phabricator.services.mozilla.com/D47373
--HG--
extra : moz-landing-system : lando
This patch changes instances where the GMP MOZ_LOG is used to prefer using
macros from GMPLog.h:
- Files that don't need their own macros now just directly call
`GMP_LOG_<LEVEL>` as required.
- Files that use their own macros for formatting have had those macro
definitions changes so that the macros have unique names and are expressed in
terms of the macros from GMPLog.h.
I've also made a couple of drive by edits to logs so that they log more than a
couple of words and updated some strings where the incorrect class name was
being logged.
Differential Revision: https://phabricator.services.mozilla.com/D47194
--HG--
extra : moz-landing-system : lando
On Android, decoded buffers need to be send back to MediaCodec in order to be
rendered and/or recycled. The current mechanism introduced in bug 1299068 only
works for playback(VideoData/VideoSink) but not WebRTC(VideoFrame/VideoOutput).
Move the callback to SurfaceTextureImage because VideoData and VideoFrame both
own that when using MediaCodec, and move the notification to VideoFrameContainer
for both VideoSink and VideoOutput pass frames there for compositing.
Differential Revision: https://phabricator.services.mozilla.com/D45771
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
In bug1583978, we are going to remove `AudibleState::eMaybeAudible`. But before that, as `AudibleState::eMaybeAudible` is only used for delaying media playback, so we can remove its usage from media element and move it to the dedicated class to reduce confusion about how and when we should use `AudibleState::eMaybeAudible` or `AudibleState::eNotAudible`.
Differential Revision: https://phabricator.services.mozilla.com/D47153
--HG--
extra : moz-landing-system : lando
Separate the logic of delaying media playback from `HTMLMediaElement`'s `mAudioChannelWrapper` to a new class, because delaying media playback is a special usage of using `AudioChannelAgent`.
It would make the code cleaner and separate the normal usage and the special usage, to reduce confusion.
We usually start `AudioChannelAgent` when media playback starts and stop it when media playback stops, however, in this case, we would start the agent even if media hasn't be started yet, because we would like to use the agent as a connection with `AudioChannelService` in order to receive the resume command when we're able to play delayed playback.
Differential Revision: https://phabricator.services.mozilla.com/D44746
--HG--
extra : moz-landing-system : lando
This change is a continuation of Part 1 (Bug 1570128), where the 2D content rendered by Firefox for Firefox Reality on Desktop is marshalled through VRHost so that it can be presented in a VR environment.
A new class, FxrOutputHandler, is created to manage creating a sharable texture, sharing it through VRShMem, and updating it when content updates. This class updates content with both WebRender and conventional rendering output.
This initial iteration of FxrOutputHandler does not have synchronization between reading and writing this shared texture across processes. A subsequent fix (Bug 1581881) is pending, which will reuse WebVR code to manage writing to and reading from a pool of textures.
This also presents issues with rendering protected media, so an additional class, FxrWindowManager, is created to manage all windows created for Firefox Reality on Desktop so that it can inform whether or not protected media can be presented.
The automated manual tests in vrhosttest.cpp now show the real shared texture handle rather than a fake value, which shows that marshaling succeeded.
Differential Revision: https://phabricator.services.mozilla.com/D46179
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
`nsIAudioChannelAgent` was created a common interface for a usage of in both js and C++ before, now we have no any JS code would use `nsIAudioChannelAgent`, it's only used in C++ code.
Therefore, in a coming refactoring (bug1580662), we will remove `nsIAudioChannelAgent` and use `AudioChannelAgent` as the only interface. Here we can make these classes start to reference `AudioChannelAgent`, instead of `nsIAudioChannelAgent`.
Differential Revision: https://phabricator.services.mozilla.com/D45748
--HG--
extra : moz-landing-system : lando
GetCurrentPhysicalThread and GetCurrentVirtualThread are, in practice,
identical, as the TLS override that GetCurrentVirtualThread depends on
is never actually set. This simply removes that and renames some things/
deletes some comments.
Differential Revision: https://phabricator.services.mozilla.com/D41247
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
`nsIAudioChannelAgent` was created a common interface for a usage of in both js and C++ before, now we have no any JS code would use `nsIAudioChannelAgent`, it's only used in C++ code.
Therefore, in a coming refactoring (bug1580662), we will remove `nsIAudioChannelAgent` and use `AudioChannelAgent` as the only interface. Here we can make these classes start to reference `AudioChannelAgent`, instead of `nsIAudioChannelAgent`.
Differential Revision: https://phabricator.services.mozilla.com/D45748
--HG--
extra : moz-landing-system : lando
Andreas Pehrson
Bogdan Tara
Byron Campen [:bwc]
Matthew Gregan
Dan Minor
Jean-Yves Avenard
Gabriele Svelto
Michael Froman
Alex Chronopoulos
Dorel Luca
Bryce Seager van Dyk
John Lin
thomasmo
alwu
Ciure Andrei
Paul Adenot
Mihai Alexandru Michis
Doug Thayer
shindli
Boris Zbarsky