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
The Adobe GMP only supports up to GMPDecryptor version 7. We're now up to
version 9. So we need to provide an adaptor to convert the old version to run
with the new interface.
MozReview-Commit-ID: 5dKreev7JMv
--HG--
extra : rebase_source : b9aa1b66ad23e9f7ddbe60b71c94c161ad974818
The Adobe GMP only supports up to GMPDecryptor version 7. We're now up to
version 9. So we need to provide an adaptor to convert the old version to run
with the new interface.
MozReview-Commit-ID: 5dKreev7JMv
--HG--
extra : rebase_source : f944a40e2287c7a7dd01a2fb145a9e5882dd2368
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
New upstream release.
This is a minor release focusing mainly on optimizations and bug fixes.
- Neon optimizations inproving performance on ARMv7 and ARMv8 by up to 15%
- Fixes some issues with 16-bit platforms (e.g. TI C55x)
- Fixes to comfort noise generation (CNG)
- Documenting that PLC packets can also be 2 bytes
- Includes experimental ambisonics work (--enable-ambisonics)
MozReview-Commit-ID: IcdnCok500X
Display dimensions are actually determined from the SPS NAL with h264 and as such we don't really care on what is found in the container (which may be incorrect).
MozReview-Commit-ID: 7JmxIawNOOn
--HG--
extra : rebase_source : 9454b07742af880cd992a92517880788bd18a712
We were previously using PacketizeFuA which stripped the NAL header. Since the
fragment fit in a single packet it would then be sent without any header
causing difficulties on the receiving side. This adds a PacketizeMode0 which
leaves the header intact.
MozReview-Commit-ID: 91rbveSuXtT
--HG--
extra : rebase_source : 95092f5e3cbb31f9c4697ed4fd272cd458eb4e94
Google's Web Platform EME tests contain a CENC PSSH box with a 0 size field.
Our existing PSSH parser in our ClearKey plugin doesn't handle this well, it
gets stuck in an infinite loop. We should really handle everything that Chrome
handles, so we should handle this input.
We also shouldn't really be using raw pointers in the PSSH parser.
So rewrite the PSSH parser to use a ByteReader, and handle an invalid 0 sized
common SystemID box.
Also add gtests for the parser, and skip over PSSH boxes with unknown SystemIDs
(if they have valid sizes that is).
MozReview-Commit-ID: CdVPpphAJV
--HG--
extra : rebase_source : e9a1b439f8b371653c2c97322a2db64cafef6dd8
Phil Ringnalda
Igor
Byron Campen [:bwc]
Alfredo.Yang
Carsten "Tomcat" Book
Jean-Yves Avenard
Michael Layzell
Glenn Randers-Pehrson
Nicholas Nethercote
John Dai
Sebastian Hengst
Alex Chronopoulos
Ralph Giles
Gerald Squelart
Nils Ohlmeier [:drno]
Wes Kocher
Ryan VanderMeulen
Michael Froman
Dan Minor
Randell Jesup
Andreas Pehrson
Adam Roach [:abr]
Matthew Gregan
Kan-Ru Chen
Iris Hsiao
Sebastian Kaspari
Myk Melez
Munro Mengjue Chiang
Michael Niedermayer
Towkir Ahmed
Daniel Holbert
Chris Pearce
Nathan Froyd
ctai
Jan-Ivar Bruaroey
Paul Adenot
Alexandre Lissy
Sotaro Ikeda
Paul Ellenbogen
Jim Chen
Tom Tromey
Kaku Kuo