Big but not complex:
- Remove the mutex
- Move all MSG thread to a new class (AudioInputProcessing)
- Remove the WebRTCAudioDataListener class, AudioInputProcessing is the listener
- Use message passing for all modifications to the AudioInputProcessing.
Differential Revision: https://phabricator.services.mozilla.com/D5442
--HG--
extra : rebase_source : 84368e8240cc47788ef2b56eb31d2a33e80e0d23
It's not maintained and probably does not work anymore.
Differential Revision: https://phabricator.services.mozilla.com/D5438
--HG--
extra : rebase_source : ccd622e40844dda5d16266e49991462d4ea94224
We don't want to notify state changed frequently if the input stream is consist of
interleaving audible and inaudible blocks.
This situation is really common, especially when user is using OscillatorNode to produce
sound. Sending unnessary runnable frequently would cause performance debasing.
If the stream contains 10 interleaving samples and 5 of them are audible, others are
inaudible, user would tend to feel the stream is audible. Therefore, we have the loose
checking when stream is changing from inaudible to audible, but have strict checking when
streaming is changing from audible to inaudible. If the inaudible blocks continue over a
speicific time thersold, then we will think the steam as inaudible.
Differential Revision: https://phabricator.services.mozilla.com/D7823
--HG--
extra : moz-landing-system : lando
The naming `isAudible` is more clear than `isInputMuted`, so also change related functionis and variables.
Differential Revision: https://phabricator.services.mozilla.com/D7820
--HG--
extra : moz-landing-system : lando
Add method to help us know whether audio block is audible or not, so that we won't
show the sound indicator for silent web audio.
Differential Revision: https://phabricator.services.mozilla.com/D7819
--HG--
extra : moz-landing-system : lando
The Windows' hardware decoder always return an image whose dimensions are multiple of 16 pixels. As such, the image coming out of the decoder is typically bigger than the wanted image.
The D3D11 documentation states that " If you try and copy outside the destination resource or specify a source box that is larger than the source resource, the behavior of CopySubresourceRegion is undefined."
We've always copied from a bigger texture into a smaller one without specifying clipping. It seems to have always worked but falls into the undefined behaviour category.
So to be extra safe, we clip the source so that it matches the dimension of the destination texture.
Depends on D8129
Differential Revision: https://phabricator.services.mozilla.com/D8203
--HG--
extra : moz-landing-system : lando
Check if we have permission from the OS to access the camera and microphone after the user has granted access to a site.
If permission is denied at the OS level, but granted to the site within Firefox, return NotFoundError.
Differential Revision: https://phabricator.services.mozilla.com/D5458
--HG--
extra : moz-landing-system : lando
P2 changed the way the H264Converter would be calling the decoder. The assumption in the EMEDecryptor was pretty incorrect to start with.
Depends on D7865
Differential Revision: https://phabricator.services.mozilla.com/D7882
--HG--
extra : moz-landing-system : lando
When used with the LowLatency option, we guarantee that the stream will contain no B-frame, as such we can reduce the re-ordering queue to zero. The apple VT decoder already returns frames in decode order making this change trivial.
Depends on D7861
Differential Revision: https://phabricator.services.mozilla.com/D7862
--HG--
extra : moz-landing-system : lando
The H264Converter can be used on a thread that isn't a nsThread or a TaskQueue, so having the H264Converter dispatching tasks isn't going to work
So instead we run all the code on the decoder's taskqueue using promise chaining.
All internal methods are made to assert that they are running on the task queue accordingly
Depends on D7860
Differential Revision: https://phabricator.services.mozilla.com/D7861
--HG--
extra : moz-landing-system : lando
Fix a bug that the current MediaRecorder's state error cases does not match the W3C spec.
pause() and resume() should throw an INVAILD_STATE_ERR only when it is inactive state, making them
independant.
Simply changing if statements is enough because the underlying encoder object (TrackEncoder) will
ignore Suspend/Resume calls when it is already suspended/recording so there won't be side-effects by
multiple pause()/resume() calls.
Differential Revision: https://phabricator.services.mozilla.com/D7910
--HG--
extra : moz-landing-system : lando
Bug 1494178 added code to mark samples with 0 encrypted ranges as unencrypted
before they were fed to the CDM. This was to catch issues where we could mark
such unencrypted samples as encrypted. However, the CDM expects certain samples
that are clear to still be marked as encrypted.
Specifically, WebM samples should be marked as encrypted if they are from an
encrypted track and have the signal byte's encryption bit set (a marker for if
the packet is encrypted), even if they have no encrypted ranges.
The WebM demuxer is already doing this. Further inspection and testing of the
mp4 demuxer shows it is behaving in line with Chromium's current mp4 parser,
which we can expect prepares its data sensibly for Widevine.
As the code removed here was added as a safety fallback, but is causing issues,
and as the demuxers already appear to be doing the right thing, the fallback
code can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D8024
--HG--
extra : moz-landing-system : lando
As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.
Depends on D7316
Differential Revision: https://phabricator.services.mozilla.com/D7318
This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback.
Depends on D7295
Differential Revision: https://phabricator.services.mozilla.com/D7296
I find it easier to read than a function pointer making you search elsewhere to see what it's about
Depends on D7294
Differential Revision: https://phabricator.services.mozilla.com/D7295
When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits.
When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT.
Differential Revision: https://phabricator.services.mozilla.com/D7294
When OOMing when allocating the temporary buffer, we return an error from the
ctor via an output parameter, and make the ConvolverNode output silence.
Additionaly, a warning is issued each time we fail to set a buffer to the buffer
property of a ConvolverNode.
Differential Revision: https://phabricator.services.mozilla.com/D6936
--HG--
extra : moz-landing-system : lando
When OOMing when allocating the temporary buffer, we return an error from the
ctor via an output parameter, and make the ConvolverNode output silence.
Additionaly, a warning is issued each time we fail to set a buffer to the buffer
property of a ConvolverNode.
Differential Revision: https://phabricator.services.mozilla.com/D6936
--HG--
extra : moz-landing-system : lando
When OOMing when allocating the temporary buffer, we return an error from the
ctor via an output parameter, and make the ConvolverNode output silence.
Additionaly, a warning is issued each time we fail to set a buffer to the buffer
property of a ConvolverNode.
Differential Revision: https://phabricator.services.mozilla.com/D6936
--HG--
extra : moz-landing-system : lando
