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