When an AudioCallbackDriver starts a fallback SystemClockDriver is running in
its stead. The AudioTrack getting fed data from the input stream of the driver
will get real data while the AudioCallbackDriver is running, and silence while
the fallback driver is running.
If the MediaStreamTrack representing the microphone source is part of a
MediaStream being played by an HTMLMediaElement; and another MediaStreamTrack
representing another source with a lower channel count than the microphone is
part of another MediaStream being played by another HTMLMediaElement; then:
1. We start the graph with the other source's output channel count, and a
fallback driver.
2. Once the audio driver has started, it adds data at a higher channel count
than the graph's to its MediaTrack. The driver switches audio driver to
match the new channel count.
3. The new driver starts with a fallback driver, which adds silence to the
track. Silence has no channel count, so the graph sees only the channel
count of the other source and switches audio driver to match this.
4. Go to 1.
This patch fixes makes us memoize a previously returned max channel count for an
AudioSegment for use when there is only null data (e.g., silence) present in the
segment. This applies to step 3 above, where no audio driver would be switched
because the graph still sees the mic's channel count.
Differential Revision: https://phabricator.services.mozilla.com/D95931
Implemented DMABufSurfaceWrapper and VAAPIDisplayHolder as a versioned class templates
as they are going to be used by both system ffmpeg and bundled ffvpx decoders.
Differential Revision: https://phabricator.services.mozilla.com/D90555
We can't handle this at the decoder level, because the decoder doesn't know that
a particular packet it's seeing is the second to last packet and it should start
trimming the end of this packet because the encoder padding spans multiple
packet.
Differential Revision: https://phabricator.services.mozilla.com/D92645
Implemented DMABufSurfaceWrapper and VAAPIDisplayHolder as a versioned class templates
as they are going to be used by both system ffmpeg and bundled ffvpx decoders.
Differential Revision: https://phabricator.services.mozilla.com/D90555
We've already had a same method in media utils, so no need to keep this one. In addition, doing that can prevent the build ambiguous error when removing autoplay related files from `dom/media`.
Differential Revision: https://phabricator.services.mozilla.com/D95878
We've already had a same method in media utils, so no need to keep this one. In addition, doing that can prevent the build ambiguous error when removing autoplay related files from `dom/media`.
Differential Revision: https://phabricator.services.mozilla.com/D95878
Some WebrtcMediaDataEncoder methods are blocking and wait for platform encoder
operations to complete. Running them in one thread pool/task queue will lead
to dead lock.
Differential Revision: https://phabricator.services.mozilla.com/D94464
Calling emplace() on instance with existing value will cause assertion.
Since Error() can be called multiple times, assignment operator is the correct way.
Differential Revision: https://phabricator.services.mozilla.com/D94463
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
There's no need to start the whole PDMFactory machinery if we know it's already disabled.
Additionally, fix tests making assumptions on the changes above.
Flyby fix for flac tests.
Differential Revision: https://phabricator.services.mozilla.com/D95242
In a coming change, when called on the main thread Supports will be made to return a true/false based on only the codec mimetype. We need a greater level of details with MediaCapabilities.
Differential Revision: https://phabricator.services.mozilla.com/D95240
This patch adds profiler markers to surface when
- The MediaFormatReader detects a change in stream id.
- The MediaChangeMonitor classes for h264 and/or vpx detect a stream change.
These scenarios typically take place before a decoder is recreated.
Because recreating a decoder is a non-trivial process that can fail and/or
result in performance issues, having these markers helps us relate such issues
to decoder recreation in profiles.
Differential Revision: https://phabricator.services.mozilla.com/D94621
This stops the log leaking into other files during the unified build this is
desirable to avoid
- Other files relying on this log macro and then breaking when unified build
boundaries shift.
- Other files getting this LOG definition unexpectedly and logging incorrectly
and/or emitting warnings due to macro redefinitions.
Differential Revision: https://phabricator.services.mozilla.com/D94743
Andreas Pehrson
Niklas Baumgardner
Byron Campen [:bwc]
Cosmin Sabou
Martin Stransky
Paul Adenot
Jean-Yves Avenard
smolnar
alwu
Dorel Luca
John Lin
Bryce Seager van Dyk
Sylvestre Ledru
Butkovits Atila
Matt Woodrow
Narcis Beleuzu
Michael Froman
Razvan Maries
Andi-Bogdan Postelnicu
Christian Holler