Although libwebrtc put keyframe interval in codec specific data
structures, it is actually used by all supported codecs and can
be shared in the common config type. This makes adding VPx specific
data structures easier.
Differential Revision: https://phabricator.services.mozilla.com/D121019
Although libwebrtc put keyframe interval in codec specific data
structures, it is actually used by all supported codecs and can
be shared in the common config type. This makes adding VPx specific
data structures easier.
Differential Revision: https://phabricator.services.mozilla.com/D121019
Right now, GetCDM is only called with aTags containing a key system string. This
patch changes the function args to reflect that. This makes it easier to reason
about the function without having to look up call sites.
Differential Revision: https://phabricator.services.mozilla.com/D122136
Right now, GetCDM is only called with aTags containing a key system string. This
patch changes the function args to reflect that. This makes it easier to reason
about the function without having to look up call sites.
Differential Revision: https://phabricator.services.mozilla.com/D122136
dom/media/gmp/GMPSharedMemManager.cpp:54:10: warning: variable 'total' set but not used [-Wunused-but-set-variable]
dom/media/gtest/TestMP3Demuxer.cpp:423:13: warning: variable 'numSamples' set but not used [-Wunused-but-set-variable]
GMPSharedMemManager.cpp updates local variable `total`, but never reads it so we can remove it.
TestMP3Demuxer.cpp updates local variable `numSamples`, but the EXPECT test checks that use `numSamples` are commented out. I don't know how to address the commented-out checks' issues, but testing that numSamples is non-negative seems a safe assumption (and a way to fix the -Wunused-but-set-variable warning).
Differential Revision: https://phabricator.services.mozilla.com/D120799
Decryptor id is no longer used anywhere functional, but we still have code
referencing and plumbing values around. This patch removes all the remaining
usage I can find in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D120647
It's better to change the input parameter's type of
`AppendAndConsumeChunk` from `AudioChunk*` to `AudioChunk&&` since the
`AudioChunk` will be consumed once it's fed to this function.
One benefit for doing so is to prevent the consumed `AudioChunk` from
being used again after it's moved/consumed. Gecko has a clang-tidy
check, bugprone-use-after-move [1], to avoid this kind of error. We
should utilize this check instead of catching used-after-move error by
human eyes.
[1]: https://searchfox.org/mozilla-central/rev/f351e19360729b351bfc7c1386d6e4ca4ea676e2/tools/clang-tidy/config.yaml#70
Differential Revision: https://phabricator.services.mozilla.com/D117714
It's better to change the input parameter's type of
`AppendAndConsumeChunk` from `AudioChunk*` to `AudioChunk&&` since the
`AudioChunk` will be consumed once it's fed to this function.
One benefit for doing so is to prevent the consumed `AudioChunk` from
being used again after it's moved/consumed. Gecko has a clang-tidy
check, bugprone-use-after-move [1], to avoid this kind of error. We
should utilize this check instead of catching used-after-move error by
human eyes.
Differential Revision: https://phabricator.services.mozilla.com/D117714
As far a I can tell, mValidMoof does the same job as mHeader and has a clearer
name. Let's just remove mHeader and make the tests a little simpler. Longer
discussion below about why we may want to separate the flags, but I'm fairly
confident that it does not apply to our current tests.
Hypothetically it may make sense to separate these flags. mValidMoof is checked
against RebuildFragmentedIndex, while mHeader is checking if the moof parser has
at least one moof. If we RebuildFragmentedIndex once and it returns true, that
implies we have a least one moof. That is the state of all our current tests
IIUC. So there is no need to have separate flags. However, if we call
RebuildFragmentedIndex multiple times, and it succeeds, then fails, and we don't
evict moofs, then we could have times where the parser still has moofs stored
internally, even if we have a failed Rebuild. But we're not doing that as far as
I can tell in these tests.
Differential Revision: https://phabricator.services.mozilla.com/D117351
Add an init segment with 2 sample description entries, each with crypto data, to
the mp4 parser gtests.
3 test cases are updated:
- We ensure the init data parses with expected results as part of our general
'does this header parse, and with what result' style test.
- We ensure expected telemetry data is gather as part of our specialized
telemetry tests. Specifically, this adds coverage to the previously uncovered
multiple sample description entries with crypto case.
- We relax the expectation that encrypted files we parse with the MoofParser
will only have one encrypted sample description entry. We now expect these
files to have at least one encrypted entry.
Note the test case has the same crypto info in both entires, so these tests do
not cover the case where we need to handle different crypto info per sample
description.
Differential Revision: https://phabricator.services.mozilla.com/D117052
Add an init segment with 2 sample description entries, each with crypto data, to
the mp4 parser gtests.
2 test cases are updated:
- We ensure the init data parses with expected results as part of our general
'does this header parse, and with what result' style test.
- We ensure expected telemetry data is gather as part of our specialized
telemetry tests. Specifically, this adds coverage to the previously uncovered
multiple sample description entries with crypto case.
Note the test case has the same crypto info in both entires, so these tests do
not cover the case where we need to handle different crypto info per sample
description.
Differential Revision: https://phabricator.services.mozilla.com/D117052
The AudioInputProcessing now needs to call ProcessInput to process the
given input data instead of processing them in NotifyInputData
Differential Revision: https://phabricator.services.mozilla.com/D116673
Each AudioInputTrack has its own AudioSegments storing the input audio
data. When the AudioInputTrack is in pass-through mode, the AudioSegment
is just the data de-interleaved from its raw data, without any audio
processing magic applied on it. If there are multiple AudioInputTracks
in pass-through mode exist in the same graph, then all of their
AudioSegments are same.
Before this patch, each of these AudioInputTracks allocates its own
space to store its own AudioSegments even those data are same. This
patch makes it possible for these AudioInputTracks to share the same
AudioSegment data they need. By creating the AudioSegment in the
NativeInputTrack, which is mapped to one specific device and is
connected to the AudioInputTrack, the AudioInputTrack can fetch the
AudioSegment data when they need and then append shared-references of
the AudioChunk, inside the fetched AudioSegment, into their own
AudioSegment. Therefore, we can have some AudioChunks created by the
NativeInputTrack and shared among the AudioInputTracks in pass-through
mode.
Differential Revision: https://phabricator.services.mozilla.com/D114801
Each AudioInputTrack has its own AudioSegments storing the input audio
data. When the AudioInputTrack is in pass-through mode, the AudioSegment
is just the data de-interleaved from its raw data, without any audio
processing magic applied on it. If there are multiple AudioInputTracks
in pass-through mode exist in the same graph, then all of their
AudioSegments are same.
Before this patch, each of these AudioInputTracks allocates its own
space to store its own AudioSegments even those data are same. This
patch makes it possible for these AudioInputTracks to share the same
AudioSegment data they need. By creating the AudioSegment in the
NativeInputTrack, which is mapped to one specific device and is
connected to the AudioInputTrack, the AudioInputTrack can fetch the
AudioSegment data when they need and then append shared-references of
the AudioChunk, inside the fetched AudioSegment, into their own
AudioSegment. Therefore, we can have some AudioChunks created by the
NativeInputTrack and shared among the AudioInputTracks in pass-through
mode.
Differential Revision: https://phabricator.services.mozilla.com/D114801
This patch plumbs the QueryOutputProtectionStatus call from the CDM up to the
MediaKeys. This is plumbing is done to get the request to an endpoint of Gecko
C++ code, and future patches will do further plumbing in order to complete the
query.
After the first query is complete, we cache the result in a CDM's
ChromiumCDMParent and update the value only when notified of changes from the
MediaKeys. This has the benefit of that checks after the first don't need to
touch the main thread. This avoids adding more main thread work, and means we
can still complete checks in a timely fashion even if the main thread is running
hot.
We cache in the parent rather than the child so that the parent can make
decisions on how to handle requests even if the CDM machinery is not yet fully
initialized. In future it may make sense to move the caching to the child, but
I'd prefer to do this only after other refactoring of the machinery which I
consider out of scope for this bug.
Future patches will ensure listeners are in place such that the cached data is
updated when updates are received further up the stack.
Differential Revision: https://phabricator.services.mozilla.com/D115415
This patch plumbs the QueryOutputProtectionStatus call from the CDM up to the
MediaKeys. This is plumbing is done to get the request to an endpoint of Gecko
C++ code, and future patches will do further plumbing in order to complete the
query.
After the first query is complete, we cache the result in a CDM's
ChromiumCDMParent and update the value only when notified of changes from the
MediaKeys. This has the benefit of that checks after the first don't need to
touch the main thread. This avoids adding more main thread work, and means we
can still complete checks in a timely fashion even if the main thread is running
hot.
We cache in the parent rather than the child so that the parent can make
decisions on how to handle requests even if the CDM machinery is not yet fully
initialized. In future it may make sense to move the caching to the child, but
I'd prefer to do this only after other refactoring of the machinery which I
consider out of scope for this bug.
Future patches will ensure listeners are in place such that the cached data is
updated when updates are received further up the stack.
Differential Revision: https://phabricator.services.mozilla.com/D115415
This patch adds an `AudioDeviceID` member in `AudioInputTrack`. This
aims to simplify `AudioInputTrack::CloseAudioInput`.
Before this patch, the `AudioDeviceID` is tracked by
`MediaEngineWebRTCMicrophoneSource` only instead so `AudioInputTrack`
has no idea of what device it pairs with. One main drawback is that
`MediaTrackGraphImpl` needs to search all the `AudioDataListener`
inside it to infer what device is closed when
`AudioInputTrack::Destroy()` is called, since `AudioInputTrack`
doesn't know what is its paired device, which gives an O(N) time
complexity, where N is the number of `AudioDataListener` in
`MediaTrackGraphImpl`
A simple way to reduce the time complexity from O(N) to O(1) is to track
the paired device when `AudioInputTrack::OpenAudioInput` is called. This
also enables the possibility to remove `mInputDeviceUsers` in Bug
1702646.
Differential Revision: https://phabricator.services.mozilla.com/D113040
The callback function itself might contains a strong reference to other object, and that reference should be clear as well when the listener explicity gets revoked, which means we won't trigger the function anymore.
If the reference doen't be clear, then it's possible to cause a memory leak if the reference eventually becomes a cycle.
Differential Revision: https://phabricator.services.mozilla.com/D110706
Current `GetElementsAfter()` is wrong, the result array would still contain the element which end time is earlier or equal to the given time.
Differential Revision: https://phabricator.services.mozilla.com/D107170