Using track_id 0 is forbidden by the mp4 spec, however, some sites still serve
media using this track_id. We've been using the 0 track ID to trigger special
handling in the MoofParser where we will parse multiple tracks, and this led us
to be tolerant of tracks using this reserved id (though we likely had some bugs
due to this).
Since sites are using this track_id, and as other browsers (and Firefox until I
broke this) tolerate such media, we should too. In order to do so correctly, we
should no longer us track_id=0 as a special case in the MoofParser, and instead
have an explicit flag, which is what this patch does.
Differential Revision: https://phabricator.services.mozilla.com/D16428
--HG--
extra : moz-landing-system : lando
Although we don't define BUILD_ARM_NEON on aarch64 (bug 1303952), aarch64
supports NEON, so we should turn on NEON for AudioNodeEngine.
OpenMAX DL doesn't support aarch64 since we modify some codes. So FFTBlock.h
still use ARM32 only.
Also, MSVC cannot use arm_neon.h header, doesn't allow
`float32x4_t zero = {0, 0, 0, 0};` and throws compiler warning.
So we need some workarounds to use this on MSVC.
Differential Revision: https://phabricator.services.mozilla.com/D16278
--HG--
extra : moz-landing-system : lando
As setting `mSuspendCalled` is enough to prevent the stream from starting, we have no need to apply unnessary audio context operation to MSG. In addition, it can avoid incorrect AudioContext's state because of out of order resume/suspend operation (https://bugzilla.mozilla.org/show_bug.cgi?id=1285290).
Differential Revision: https://phabricator.services.mozilla.com/D15679
--HG--
extra : moz-landing-system : lando
If media element is used as a source for AudioContext, we would try to start AudioContext which was not allowed
to start when media element starts playing.
Differential Revision: https://phabricator.services.mozilla.com/D14593
--HG--
extra : moz-landing-system : lando
In order to call this method on other situations, rename it to 'StartBlockedAudioContextIfAllowed()'.
Differential Revision: https://phabricator.services.mozilla.com/D14592
--HG--
extra : moz-landing-system : lando
Processing MediaCodec output in Android binder threads while flushing
in task queue could cause race condition and leftover frames. Dispatch
the processing to task queue ensures all frames prior to flushing will
be cleared (by mDecodedData.Clear()) or ignored (by mInputInfos.Clear()).
Also consolidate all flushing operations in one task to avoid frame
insertion between emptying mDecodedData and mInputInfos.
Differential Revision: https://phabricator.services.mozilla.com/D15228
--HG--
extra : moz-landing-system : lando
Usually the threshold is reset internally in MediaDataDecoder subclasses
that support the hint in their Flush() implementations so the value
will start fresh after seeking completed. But sometimes when there are
consecutive seek requests, MediaFormatReader::DecoderData::Flush() could
return early because DecoderData::mFlushed stays true when there is no
sample demuxed yet, and the threshold will not be cleared. Also, in
MediaFormatReader::SetVideoDecodeThreshold() we decide not to set the
hint when the seek target is close to EOS by checking the existence of
the next keyframe, and that could fail when there are gaps between MSE
buffered ranges. To make sure the hint is never out of date, we should
clear it rather than leaving it untouched.
Differential Revision: https://phabricator.services.mozilla.com/D15227
--HG--
extra : moz-landing-system : lando
Handle mp4parse-rust providing cbcs data in the track metadata. Explicitly check
the crypto scheme we get in the metadata and error if we encounter something
outside of cenc and cbcs -- catch unexpected data early.
Differential Revision: https://phabricator.services.mozilla.com/D15878
--HG--
extra : moz-landing-system : lando
Rework our mp4 sample iterator to handle cbcs crypto data.
To support this we populate the following new data for samples:
- Crypto pattern information, this is split into a count of encrypted blocks
and a count of clear blocks.
- A constant IV.
This information is available at a track level and a sample group level. The
sample group level supersedes track level information if both a present.
Prior to this patch, some crypto information was written to samples in
the SampleIterator in Index.cpp, and some in the MP4Demuxer (based on if the
SampleIterator had not populated the data). This patch moves all these
operations into the SampleIterator -- the idea being that the sample iterator
should be the component responsible for setting up sample meta data.
Differential Revision: https://phabricator.services.mozilla.com/D15877
--HG--
extra : moz-landing-system : lando
Explicitly store the crypto scheme being used on our crypto structs to let us
differentiate between cenc and cbcs data. In doing so remove mMode and replace
mValid with IsEncrypted() for the following reasons:
- Different modes within the existing schemes are not currently utilized by the
spec: the scheme implies mode. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by the spec --
possibly if the isProtected flag which we were tracking with mMode, is
ever changed to be more than a bool in the spec.
- mValid was typically used to check if these structs contained valid crypto
data or not. With only one scheme this was often shorthand for 'IsEncrypted',
but with multiple schemes what is considered valid data for one may not be for
another. Do away with this and just explicitly have an 'IsEncrypted'.
Differential Revision: https://phabricator.services.mozilla.com/D15874
--HG--
extra : moz-landing-system : lando
Handle mp4parse-rust providing cbcs data in the track metadata. Explicitly check
the crypto scheme we get in the metadata and error if we encounter something
outside of cenc and cbcs -- catch unexpected data early.
Differential Revision: https://phabricator.services.mozilla.com/D15878
--HG--
extra : moz-landing-system : lando
Rework our mp4 sample iterator to handle cbcs crypto data.
To support this we populate the following new data for samples:
- Crypto pattern information, this is split into a count of encrypted blocks
and a count of clear blocks.
- A constant IV.
This information is available at a track level and a sample group level. The
sample group level supersedes track level information if both a present.
Prior to this patch, some crypto information was written to samples in
the SampleIterator in Index.cpp, and some in the MP4Demuxer (based on if the
SampleIterator had not populated the data). This patch moves all these
operations into the SampleIterator -- the idea being that the sample iterator
should be the component responsible for setting up sample meta data.
Differential Revision: https://phabricator.services.mozilla.com/D15877
--HG--
extra : moz-landing-system : lando
Explicitly store the crypto scheme being used on our crypto structs to let us
differentiate between cenc and cbcs data. In doing so remove mMode and replace
mValid with IsEncrypted() for the following reasons:
- Different modes within the existing schemes are not currently utilized by the
spec of implementation. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by the spec.
- mValid was typically used to check if these structs contained valid crypto
data or not. With only one scheme this was often shorthand for 'IsEncrypted',
but with multiple schemes what is considered valid data for one may not be for
another. Do away with this and just explicitly have an 'IsEncrypted'.
Differential Revision: https://phabricator.services.mozilla.com/D15874
--HG--
extra : moz-landing-system : lando
Avoid resetting volume in every AudioSink restart to stop unexpected volume change during play/pause and seek. Volume changes could occur if the volume has been modified outside firefox (for example pavucontrol in Linux).
Differential Revision: https://phabricator.services.mozilla.com/D15210
--HG--
extra : moz-landing-system : lando
Processing MediaCodec output in Android binder threads while flushing
in task queue could cause race condition and leftover frames. Dispatch
the processing to task queue ensures all frames prior to flushing will
be cleared (by mDecodedData.Clear()) or ignored (by mInputInfos.Clear()).
Also consolidate all flushing operations in one task to avoid frame
insertion between emptying mDecodedData and mInputInfos.
Differential Revision: https://phabricator.services.mozilla.com/D15228
--HG--
extra : moz-landing-system : lando
