Primetime PSSH boxes don't use the common encryption system ID.
So to ensure we don't break any existing Primetime players, we
must allow PSSH boxes with the Primetime system ID to pass the
PSSH validator.
MozReview-Commit-ID: 3q58FKLQXgV
--HG--
extra : rebase_source : aac2a8349d8e9dfccae3c37a47549245fb1fc0e3
The expected value comes first in the EXPECT_EQ gtest macro. So reorder our
calls to this macro in the Pssh Parser gtests to match that.
This makes it easier to read what's the expected value when the test fails.
MozReview-Commit-ID: LJ4ND2gRPi4
--HG--
extra : rebase_source : 85ca2dcff57354253b801fbd598c89698c74c2d6
We're now obliged to be stricter, taking from the example of the Web Platform
Tests.
MozReview-Commit-ID: AJNDoRZ9BF8
--HG--
extra : rebase_source : 79b13d1d7d1b6b6b4a382b6a17af81606af608fa
This better reflects that it's used for all CENC keys, not just ClearKey keys.
MozReview-Commit-ID: 9uCzDKVDLjc
--HG--
extra : rebase_source : dfd7fe864be6825a86dfed4f60b448a5edac286f
Now that we can link gmp-clearkey's PSSH parser into Gecko, we can
simply use that inside MediaKeySession to validate that the CENC
init data matches the spec.
This change enforces that CENC init data uses the common system Id.
As far as I can tell, Widevine only uses that now.
MozReview-Commit-ID: HrlKQHcv5DI
--HG--
extra : rebase_source : ccf8e217d87dfa85478578f52469dc7383fd6c9b
We're loading functions from that library dynamically in gmp-clearkey anyway,
we don't need to statically link this.
MozReview-Commit-ID: AKwP5aWLsK3
--HG--
extra : rebase_source : 23ab95e7bb2f756ef1df7f97b96ec7da0953533f
To validate the PSSH init data passed to EME, I'd like to reuse the same
PSSH parser that the ClearKey CDM shared library uses. So move the code
out of gmp-clearkey and into its own library, so we can link it statically
into code that needs to use it.
MozReview-Commit-ID: 7xSUSmCueJz
--HG--
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.cpp => media/psshparser/PsshParser.cpp
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.h => media/psshparser/PsshParser.h
extra : rebase_source : 3f621aa1d99c6a73f6b5f3ca9d1f84022266a833
Things seem to build OK without this, and it's breaking some new code I added in gyp_reader.
MozReview-Commit-ID: 6ccaXZ0mRTj
--HG--
extra : rebase_source : c1e8acb39f863b3ff62492cf70e74748cb74e795
The DtmfInband class does not support sample rates above 32000. This adds
support for 44100 and 48000.
The 'a' coefficients were calculated in python as:
int(round(32768*math.cos(2*math.pi*f/fs)))
The 'ym2' coefficients were calculated in python as:
int(round(16383*math.sin(2*math.pi*f/fs)))
where f was in: [697, 770, 852, 941, 1209, 1336, 1477, 1633] and fs was in:
[8000, 16000, 32000, 44100, 44800].
The calculated values were slightly off the existing values at 8000 Hz,
but agreed at 16000 and 32000 Hz.
MozReview-Commit-ID: GIzyUSyecR4
--HG--
extra : rebase_source : edbde6e8c8b6cfd1c44c808022849c688364745b
When we add SPS/PPS NAL in front of each keyframe data, this somehow makes the WMF decoder to misbehave and to always return an invalid timestamp.
MozReview-Commit-ID: 2SzTiwP0ii1
--HG--
extra : rebase_source : b499c83d504df772e6d722053630ff4d92306d4f
The DtmfInband class does not support sample rates above 32000. This adds
support for 44100 and 48000.
The 'a' coefficients were calculated in python as:
int(round(32768*math.cos(2*math.pi*f/fs)))
The 'ym2' coefficients were calculated in python as:
int(round(16383*math.sin(2*math.pi*f/fs)))
where f was in: [697, 770, 852, 941, 1209, 1336, 1477, 1633] and fs was in:
[8000, 16000, 32000, 44100, 44800].
The calculated values were slightly off the existing values at 8000 Hz,
but agreed at 16000 and 32000 Hz.
MozReview-Commit-ID: GIzyUSyecR4
--HG--
extra : rebase_source : 108bdbc492a58f1532a5629680753e7395a916ae
Having these files in-tree makes it possible to run
`cargo test` to verify changes.
MozReview-Commit-ID: 6x4XZaw4UtD
--HG--
extra : rebase_source : 293572cbbc21929b43a735bf53ddb5521503bcd2
The byteorder dependency was moved to $topsrcdir/third_party/rust/
in bug 1298422 but this import script wasn't updated.
MozReview-Commit-ID: CzoxsFPYpIm
--HG--
extra : rebase_source : 18bcc2e3351887f0593e2167acc59c6c4f6003e8
Altered copies of the base test case helps verify different duration overflow
boundaries.
Track durations are now checked (including for previous test cases).
MozReview-Commit-ID: CeOtnAAg1mg
Use CONFIG['NEON_FLAGS'] on moz.build instead.
MozReview-Commit-ID: F6R532Hi5mg
--HG--
extra : rebase_source : 7243f316de3138c702f09b336f6d430e6c9c15b5
Result of running the update script, followed by `cargo update`
in tookit/library/rust/.
MozReview-Commit-ID: LNdvuOqVx9a
--HG--
extra : rebase_source : 70b263d1ba1867b5b2b907530fab4beedc25ae56
We do so by checking the frame data for NAL of type 5 as per ISO IEC 14496-2.
MozReview-Commit-ID: JFeLysrZ6aG
--HG--
extra : rebase_source : edf599210fd3a995f3538a7e54e083894620bf9e
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
Result of running the update script and updating gecko's
integration crate for the layout change.
MozReview-Commit-ID: GaIMFKmPmtf
--HG--
extra : rebase_source : 0d3a2f1d211840879e562cb56afcc9ef7e38c730
This release splits the capi into a separate crate and adds
mp4parse_is_fragmented() for vp9 support.
MozReview-Commit-ID: JkwylmdfPa9
--HG--
extra : rebase_source : b74b7e20aaf49fe1b2b7121562352c755db3aff3
DiscardRemaning was needed to prevent debug-time assertion that the buffer was
read completely or explicitly discarded.
However this required extra work in cases where buffer didn't need to be read
to the end.
And also it could cause crashes (in debug versions) if a buffer was not fully
read, be it because the parser was incorrect or because the media file itself
was wrong (though possibly still readable despite that).
Finding parser issues is still possible by manually instrumenting ByteReader
during development.
And reading media file with small recoverable errors is a bonus.
MozReview-Commit-ID: 2RUYzaYAeRW
--HG--
extra : rebase_source : 26c41758b1b2c87542bf4e41d08e361198ca5b13
This is done by moving FlacFrameParsers' AutoByteReader to a more public spot
in libstagefright's bindings.
Using AutoByteReader means there is no more need for explicit calls to
DiscardRemaining(); which means our parsers relying on BoxReader will be more
lenient about boxes that are larger than needed.
MozReview-Commit-ID: 3EERU749WYB
--HG--
extra : rebase_source : 6deba02ac553303b0a2b694c24bfcb54c2e732b1
Also ByteReader and AutoByteReader are marked RAII, to help prevent misuses.
MozReview-Commit-ID: 7oklXs4QMnq
--HG--
extra : rebase_source : 54fca3168a70d951e6012baea4bf0544827cae11
Setting the capture_time_ms to -1 causes RTCPSender::SetLastRtpTime to ignore
it and use the current clock time. The default value of 0 will be used in the
the calculation in RTCPSender::BuildSR and cause mismatched timestamps.
MozReview-Commit-ID: IK8lLK8Rmla
--HG--
extra : rebase_source : 6aac4f8f2a5336280c6c0c36386f990b490bff2c
Sometimes a track is added to a stream synchronously (before the stream is
exposed to script), and sometimes asynchronously (see the mediacapture-main spec
on the "addtrack" event).
In the latter case we might still need to create the MediaStreamTrack object
synchronously for tracking purposes. CaptureStream of Media element playing a
MediaStream wants this.
MozReview-Commit-ID: 7me8xzN7rwj
--HG--
extra : rebase_source : 4f129b127b855e47aad2ae9ab3981ffde057412d
Memory allocations for which the size is based on media data are now fallible,
and therefore no OOM should happen there.
MozReview-Commit-ID: BGWOPDcBbLw
--HG--
extra : rebase_source : 1a30c68135ff46b5f2ca02bd7a40dd27cbb8eac8
Extracted from the H264 codec and using the stagefright one.
MozReview-Commit-ID: ENjsDvB9MYp
--HG--
extra : rebase_source : 293d8e184cc7b326e6b84d038fd98ff94703f31e
H264 decoders always use those anyway, so may as well use them in the demuxer if SPS NAL is available.
This guarantees that we have correct dimensions when reading the MP4 metadata, and will have the side benefit that when loadedmetadata is fired, the dimensions provided at the time will be final; not having to wait to decode the first frame.
MozReview-Commit-ID: 3j70Xqw8jJY
--HG--
extra : rebase_source : 6bc0f1fa1c2db35bcaa683cc1a68042d122e2892
Extracted from the H264 codec and using the stagefright one.
MozReview-Commit-ID: ENjsDvB9MYp
--HG--
extra : rebase_source : 51b92215622df8cdcb65453013ab8022923dd9e8
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
https://github.com/kinetiknz/cubeb/commit/6b2c610 changed the output unit
from kAudioUnitSubType_DefaultOutput to kAudioUnitSubType_HALOutput because
capture is never available on the DefaultOutputUnit. For the case where
we're doing output only to the default device, this regressed the automatic
device switching when the output device was changed in the Sound system
preferences. Reverting to the DefaultOutputUnit for this case restores the
previous behaviour. This addresses BMO #1278612.
Use fallible allocations for arrays that could get arbitrarily long
(independant of the media file size.)
MozReview-Commit-ID: LWiKFVpYK5d
--HG--
extra : rebase_source : bc603c30214768b9a39c83bd92bc0df31d1498e4
Only added the new test case, but it actually works fine, so the test will need
to be extended to cover the failure found in that bug.
MozReview-Commit-ID: FAU5UvkyOfD
--HG--
extra : rebase_source : fbdddecf6058662ae850366bb5f0c3afb691dd10
Well, this is embarrassing: The MoofParser test was not parsing anything,
because it was given an empty byte range!
Also HasMetadata() has to run before RebuildFragmentedIndex(), because the
latter moves the offset and would then leave nothing for the former to read.
MozReview-Commit-ID: ZB35lc8iaE
--HG--
extra : rebase_source : feff313beb159c6b22361fabc188d33fa4b93220
This patch makes the following changes on many in-class methods.
- NS_IMETHODIMP F() override; --> NS_IMETHOD F() override;
- NS_IMETHODIMP F() override {...} --> NS_IMETHOD F() override {...}
- NS_IMETHODIMP F() final; --> NS_IMETHOD F() final;
- NS_IMETHODIMP F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 386ee4e4ea2ecd8d5001efabc3ac87b4d6c0659f
This patch changes |virtual NS_IMETHODIMP| occurrences to |NS_IMETHOD|, which
is equivalent and the more standard way of marking in-class virtual XPCOM
methods.
--HG--
extra : rebase_source : c0ad273d8e341a7601466f33420a62742130e4a6
We need to call SetReceiveCodec for RED and ULPFEC so we know how to handle
those packets when received.
MozReview-Commit-ID: A9EluM7p2NH
--HG--
extra : rebase_source : 14033558254e7b8c7bc8dc38c1b77ad371b4e6a5
To be able to send and receive video with FEC enabled it appears we need to
have matching constant values here and in sdp/sipcc/ccsdp.h.
MozReview-Commit-ID: LZzAyMW9eEu
--HG--
extra : rebase_source : 1b0588b53c3906659711ab39d51533ae38db2568
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
I also added more testing around ClearKey's base64 decoding, since that affected
how keyIds were handled.
MozReview-Commit-ID: 2UH1JNT4NC3
--HG--
extra : rebase_source : 8e2c861e6b030d7e4a1378d3fafed7630324d940
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
Saving is disappointing, only 41kiB out of a 2222kiB
MozReview-Commit-ID: JNz9PxHTLUp
--HG--
extra : rebase_source : b68ed5c3784c76d840438d1d5e369c95a8abd9a7
Replace |MediaPipelineTransmit::PipelineListener::NotifyQueuedTrackChanges| with |MediaPipelineTransmit::PipelineVideoSink::SetCurrentFrames|. We only need to deal with the video case since audio will be routed to |NotifyQueuedAudioData|.
MozReview-Commit-ID: EVpMVgJynGT
--HG--
extra : transplant_source : %0By%B5%91Fr%5B%BA%F7%D4%EE%FBs7%0C%F2%84%EC%5C5
This patch is really two separate changes.
The first change is that rust crates are large, standalone entities that
may contain multitudes of source files. It therefore doesn't make sense
to keep them in SOURCES, as we have been doing. Moving to use cargo
will require a higher-level approach, which suggests that we need a
different, higher-level representation for Rust sources in the build
system.
The representation here is to have the build system refer to things
defined in Cargo.toml files as the entities dealt with in the build
system, and let Cargo deal with the details of actually building things.
This approach means that adding a new crate to an existing library just
requires editing Rust and Cargo.toml files, rather than dealing with
moz.build, which seems more natural to Rust programmers. By having the
source files for libraries (and binaries in subsequent iterations of
this support) checked in to the tree, we can also take advantage of
Cargo.lock files.
The second is that we switch the core build system over to building via
cargo, rather than invoking rustc directly.
We also clean up a number of leftover things from the Old Way of doing
things. A number of tests are added to confirm that we'll only permit
crates to be built that have dependencies in-tree.
When we call MediaPipeline::UpdateTransport_s we in turn call DetachTransport_s
which detaches the pipeline from PipelineTransport. The subsequent call to
AttachTransport_s does not currently reattach the pipeline, causing
subsequent sends to fail due to a detached pipeline. Since
PipelineTransport::SendRtpRtcpPacket_s returns NS_OK if a send fails due to a
detached pipeline, this failure is not straightforward to detect.
This patch adds an Attach() method to PipelineTransport and calls it from
AttachTransport_s.
MozReview-Commit-ID: Kfc3TH1YOno
--HG--
extra : rebase_source : 91dbb07973b62e410541150805a918e4375643af
Replace |MediaPipelineTransmit::PipelineListener::NotifyQueuedTrackChanges| with |MediaPipelineTransmit::PipelineVideoSink::SetCurrentFrames|. We only need to deal with the video case since audio will be routed to |NotifyQueuedAudioData|.
MozReview-Commit-ID: EVpMVgJynGT
--HG--
extra : amend_source : 19b5fca8cc2ca10d58bd8b2add9363ff9bd42b62
Replace |MediaPipelineTransmit::PipelineListener::NotifyQueuedTrackChanges| with |MediaPipelineTransmit::PipelineVideoSink::SetCurrentFrames|. We only need to deal with the video case since audio will be routed to |NotifyQueuedAudioData|.
MozReview-Commit-ID: EVpMVgJynGT
--HG--
extra : transplant_source : U4%AC%EA%CA%CE%15%D6%F6%F8%05%F5%ED%FB%8EF%EF%E1X%13
Google's Web Platform EME test expects this, and it makes sense.
MozReview-Commit-ID: CCuEHYintob
--HG--
extra : rebase_source : 7b2a9f38b5c22ecb0af8b9a2e270eaa7d0bf2da0
