This fixes a quality issue with the surround-sound encoder
handling loud signals.
MozReview-Commit-ID: EkzEqs9io6N
--HG--
extra : rebase_source : 15e31af6865f0726beae0a988cb986bd182bac8e
This refactor is for exposing necessary symbols of libpng for freetype2 in a
general way. Currently the necessary symbols of libpng for freetype2 are
exposed only on Android. And whether these symbols are exposed solely depends
on the target platform checking. A better way to decide whether or not to
expose these symbols would be checking the dependency of freetype2 directly.
When I added this check during the modifications for Bug 1345511 (Move
nICEr stun local address discovery to an IPC call to enable future
sandbox restrictions on content process) I originally thought this was
more of an error condition, but it really isn't. It can happen each
time the following method(s) is called:
PeerConnectionMedia::EnsureTransports() ->
GatherIfReady() ->
EnsureIceGathering_s()
MozReview-Commit-ID: Ct3teqXBxWd
--HG--
extra : rebase_source : a116a8423fd999c4746e9375b8f42a6d908a1ea7
- Avoid any potential for this going away from underneath the dispatch
to STS thread.
- Added notes in PeerConnectionImpl on the test-only nature of the
AddRIDExtension, AddRIDFilter, and GetMediaPipelineForTrack methods.
PeerConnectionImpl::GetMediaPipelineForTrack by returning a reference
to the RefPtr instead of a copy.
MozReview-Commit-ID: EwMr9ulKtm8
--HG--
extra : rebase_source : 55c8b14f63020feda57accd2b4b331de708866c4
Now that Chrome release is bundle-aware, let's reapply the patch to
properly emit port 0 for m-lines in sections with the bundle-only
attribute.
MozReview-Commit-ID: 8RftSXIzIpD
--HG--
extra : rebase_source : 6f9c4cb6b322aec7c00060827e1f5e7852f8acfc
Otherwise AnnexB::IsAVCC will return false on those converted samples.
MozReview-Commit-ID: 6OBV6L49InL
--HG--
extra : rebase_source : b4c315583392cfe455d0932f4345a8a02e367f2f
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
I had removed the USE_YASM define in porting the libvpx
moz.build to libaom, to avoid depending on VPX_USE_ASM.
Turns out USE_YASM is a magic context define, without which
the build won't compile libaom's yasm-format .asm files,
so we need to define it for the two intel architecture
source sets.
Restore the define unconditionally for intel targets.
We require yasm in the default build for those targets,
and want to fail if it isn't available to block performance
regressions.
MozReview-Commit-ID: CqGtY8RNLNf
--HG--
extra : rebase_source : ccc7f9dfc467642d9e4c623c55e54e769fb38f2f
We no longer support 32-bit x86 macOS, and
these flags point to configurations we
don't generate.
MozReview-Commit-ID: 3mIfHCf6aUj
--HG--
extra : rebase_source : 35b5089ade7f9d5d03e5f4d3f0760cc969b4b8c7
Now that RID filtering (Bug 1358224) has fixed the intermittant oranges
from Bug 1351531 and 1351590, remove the functionality from MediaPipeline.
MozReview-Commit-ID: 1rED3iaHRCK
--HG--
extra : rebase_source : 5539f9badc99a8abfcf5419b436718233e9ab567
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
Result of running generate_sources_mozbuild.sh.
MozReview-Commit-ID: DFmYUs5LRlG
--HG--
extra : rebase_source : 5360198dfe600017d4c5f624cdefe569cdfccc9e
This is a port of the libvpx scripts, themselves a port of
Chromium's scripts to generate an external build description
using hooks in the upstream configure and make scripts.
The libaom library is a fork of libvpx so we can use a similar
approach.
I've put the upstream source in $(topsrc_dir)/third_party/aom
but the build description and any patches are under the media
directory with the other codecs, similar to how zlib works.
Config files and headers generated by the upstream build system
are also under $(topsrc_dir)/media/libaom/.
MozReview-Commit-ID: ATLgOTPD2i1
--HG--
extra : rebase_source : c0fdcdb41a5bac5fdf64f773458cb62937fc9dd8
Turns out since Firefox doesn't receive simulcast streams, we never
noticed this leak. Convert RTPHeaderExtension.rid from a char* to
rtc::scoped_ptr<char[]> so it gets deleted properly. This also
requires a new copy constructor and assignment operator.
MozReview-Commit-ID: Jh4Gp4dAl9g
--HG--
extra : rebase_source : 8c1081fecd6e56a8f932af54fbd294adb85866f5
The simulcast mochitests setup the receiving PeerConnection to receive
simulcast video streams which Firefox doesn't really support. Without
a test media server, this is about the best we can do and still test
simulcast.
Unfortunately the two simulcast streams arriving with different ssrcs
(as expect) exercises code we have to deal with some services switching
ssrcs midstream. In the tests, this causes intermittent failures
because the test is waiting to receive a certain ssrc, and the receiving
VideoConduit has switched to the other ssrc.
This change adds the ability to filter on RID at the MediaPipeline level,
which we can setup prior to media flowing. This avoids the ssrc switching
issue since the VideoConduit only receives one ssrc until we change the
RID filter to the second RID. At that point, the VideoConduit sees a new
ssrc and the switching code works as intended.
The modified mochitests setup the RTP stream id header extension, and then
filter on each of the RTP stream ids in turn.
MozReview-Commit-ID: KApfaxMX8rl
--HG--
extra : rebase_source : d7ae88d9675acd7b3700f342ca6a68d0bbb0ced5
The simulcast mochitests exhibit an intermittent failure due to ssrc-based
filtering that can be solved by filtering by RID. The RTP header parser
used in MediaPipeline also needs to have the RID RTP header extension
specified in order for it to properly parse the RTP header and allow
filtering on RID.
MozReview-Commit-ID: E54HCGLVYDk
--HG--
extra : rebase_source : b53085f23cb6558611aa7622f55637e19439c9c3
Pull recent changes from the upstream nestegg webm parser
repo. This include a definition of NESTEGG_CODEC_AV1 for
supporting the Alliance for Open Media's AV1 video codec,
and a fix for an unitialized variable warning.
MozReview-Commit-ID: EC1WsaFYlqo
--HG--
extra : rebase_source : 22139c35e505b9cf3c165ff76cdfaaea953baf4d
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
Its content is a no-op since bug 1322707.
The code in the same directory, though, is meant to move to gtests
(bug 1316611).
--HG--
extra : rebase_source : fa269a034fd327856fde8d0673de58eba9b02d8e
mRustTestMode is only declared when not in RELEASE_OR_BETA, so we must guard
all its uses.
The one in GetTrackInfo was a mistake, it shouldn't have been used there, as
we always want to compare results (without crashing) and report differences as
a warning.
The other ones just need the `#ifndef RELEASE_OR_BETA` guard.
MozReview-Commit-ID: LE31viVyhov
--HG--
extra : rebase_source : 5aed13d02c3a1ef27627bbf687d9aef05dcbf8ac
In addition to the returned MediaResult, a special number-of-tracks value
(not just 0) indicates an unrecoverable error.
For Rust-vs-Stagefright comparison purposes, an error is considered the same
as 0 (because Stagefright never returns errors, but Rust may, so complaining
about that would be too noisy, and useless to us.)
MozReview-Commit-ID: IwadWSOIWr4
--HG--
extra : rebase_source : 29f53ee6a02a0431adb0b615a122a4e7b480108c
The returned MediaResult is used as error or warning in MP4Demuxer::Init().
MozReview-Commit-ID: Bnv4xG8bCJ4
--HG--
extra : rebase_source : c1952ed61396834b0cd7da58c9b64481a5c46ab1
This was meant to be temporary, and we can remove it now.
MozReview-Commit-ID: 2A9RKIabYIZ
--HG--
extra : source : e6cd7e39bfdd77772ffd3a36448b7763db7ec6d1
extra : histedit_source : dcb1bd9d144aaa9abeef38107a6ee6d85cdf7b2f
The webrtc gyp files have a 'build_for_tool' flag that controls among other
things what defines are provided at build time. This meant that during a
firefox valgrind build webrtc would still specify NVALGRIND, thus disabling
some valgrind macros. Similarly there are flags for asan and tsan that we
should probably have been specifying as well. This patch sets the
'build_for_tool' flag to the appropriate value when building under valgrind,
asan, and tsan.
This updates mtransport logging to explicitly include prlog.h and defines
MOZ_MTLOG in terms of PR_LOG rather than MOZ_LOG when building outside of XUL.
We used to get the symbols we need using `LoadLibrary`, but now (since
661c653c86),
we can statically link to avrt.lib, because we only support Windows OSes that
have this library. For now, this works because avrt.lib is linked in
webrtc-land somewhere with a #pragma, but:
- We're going to stop using this bit of webrtc in the near future (around
Firefox 54)
- Not linking this explicitely where it's used breaks --disable-webrtc, that is
a popular option
MozReview-Commit-ID: 7b16Kdl3VUu
--HG--
extra : rebase_source : b4159872427b4e9d912e1228e75563ca9a8e828d
The WMF decoder gives us video frames in buffers with the planes 16 row-aligned
for some reason. If we allocate our video frames the same size we waste memory.
So let's have the ClearKey CDM not allocate its video frames with the extra
padding rows.
Excluding the padding in our copy of the decoded data also makes my work in bug
1351953 easier.
MozReview-Commit-ID: 9dD40P6ST68
--HG--
extra : rebase_source : a6c4fea01e8bf2deef8edc78d0a041e8fed0c0b8
extra : source : 433028f9a2055869cd98710f0871d040605c0535
The support to namespace prefixing in moz-cheddar means we
can simplify exported enum names on the rust side. However
this makes for some spelling changes on the C side.
MozReview-Commit-ID: 4t6NDusx0uI
--HG--
extra : rebase_source : 1c1221507ce42965486d79e6809d1541f6410f55
This adds a stub implementation for nsTraceRefcnt::WalkTheStack which we're
pulling in from <mozilla/Assertions.h> in some debug builds.
MozReview-Commit-ID: 6wVghIfKWWZ
--HG--
extra : rebase_source : 1e8472935c7f8ac486794fab764e08b30eea79ed
This adds a moz.build file for the tests. The alternative would be to hack up
the gyp files. Since gyp support has already been removed from upstream, this
does not really buy us anything as far as maintainabily goes. Once gn support
is available in our build system, we can remove this moz.build file and use
the gn files instead.
The include paths for the gtest and gmock headers in the webrtc.org tests are
not compatible with where we export the headers. We could patch each unittest,
but the include location has already changed upstream making this painful
to maintain. Instead, we duplicate the relevant headers to the expected path.
MozReview-Commit-ID: 1ADUAMxTCFq
--HG--
extra : rebase_source : 2cc10faa7018ee8af8e8f3d7805265ed2dd89507
This adds gflags to the list of ignored directories for clang static
analysis and adds "explicit" where required in mutex.h.
We also stop building a duplicate copy of snprintf for windows as our builds
already include a definition for it.
MozReview-Commit-ID: 4uMhTMvAKL0
--HG--
extra : rebase_source : d63d3797053c7720c725b3994cb3b2ca11bb191f
These were written for the signaling tests but are no longer needed there
because those tests link against libxul. They are still useful for the
webrtc.org unit tests, so we should move them there.
MozReview-Commit-ID: GVskiZebq19
--HG--
rename : media/webrtc/signaling/test/FakeIPC.cpp => media/webrtc/trunk/gtest/FakeIPC.cpp
rename : media/webrtc/signaling/test/FakeIPC.h => media/webrtc/trunk/gtest/FakeIPC.h
extra : rebase_source : 57b70f5dd3a55e73de0b066f228ddf957f477c26
Building these as part of the webkit lib adds unnecessary dependencies on Mozilla code for things that only case about the webrtc static lib.
MozReview-Commit-ID: 7ThU7hAwRX0
--HG--
extra : rebase_source : eef256711e205d023a647e6196dcc61e657f6e28