Both of these libraries call into libm for various reasons, but by
linking with the C++ compiler on most platforms, they never had to
declare their dependency on libm. Future changes will make these
libraries link with the C compiler, which won't automatically link with
libm, so we need to make the dependency explicit prior to that change.
We can avoid the symbol visibility problem by putting
sanitizer/asan_interface.h in the config/system-headers.
--HG--
extra : rebase_source : bc81a81ef8970c3544febf06631740208583c7fa
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
New upstream release. Fixes an issue where the encoder would
incorrectly bandlimit signals to 12 kHz.
MozReview-Commit-ID: 91LsUhXDlxT
--HG--
extra : rebase_source : a7c476f073536521e614479e9e809a95b8873b07
This allows tests to implement different packet handling schemes without having
to extend or modify TestNat itself.
MozReview-Commit-ID: 6DlESF3hfX6
--HG--
extra : rebase_source : ebb621f6f6ba00811cda7baef449caec126cb15e
New upstream release. Fixes an issue where the encoder would
incorrectly bandlimit signals to 12 kHz.
--HG--
extra : rebase_source : 258692afe5a5d9602c76e71a679225bcd90951ef
The test is rewritten to use mock implementations which are subclassed from real
implementations rather than using conditional compilation and separate classes.
MozReview-Commit-ID: 3jBEtEdNQOB
--HG--
rename : media/webrtc/signaling/test/mediapipeline_unittest.cpp => media/webrtc/signaling/gtest/mediapipeline_unittest.cpp
extra : rebase_source : dcf514c30793b67cc4114acd3f7fa1d01094df26
They can change from one SPS to the next, causing unecessary reconstruction of the decoder.
MozReview-Commit-ID: IhCnLuzGc2i
--HG--
extra : rebase_source : ff6020c10fe9d2eaee7ee8244c92d0c1535239be
We now compare the decoded data rather than the raw data, otherwise as seen in video from bug 1372766, we keep draining the decoder. For some reasons the SPS NALs only differ by 1 byte at a time.
MozReview-Commit-ID: LdXinUZHjD4
--HG--
extra : rebase_source : 0aa768cbcbe5b6df0a2a01df1db61c93537899a2
All decoders appear capable of handling content change when just new PPS appears.
So we restrict the test to SPS changes.
MozReview-Commit-ID: LPSfMaTIj6C
--HG--
extra : rebase_source : f2a757e71dfab7938da4f064d073fc21f99edf53
We will use them to simplify the parsing of the extradata.
MozReview-Commit-ID: 5M5uGXAkkFb
--HG--
extra : rebase_source : bbd641203eb8bdcccb667d1a4e259c1a0462b11e
With some H264 streams, we find that the SPS/PPS NALs are duplicated on the stream. This caused us to treat it as if the content changed due to the discrepency between the extradata found in the MP4 metadata and what found inband.
When scanning for SPS NALs, we now attempt to detect duplicates, and if so ignore them.
MozReview-Commit-ID: D8OVOXSwEkY
--HG--
extra : rebase_source : cbaccee3d2b3d73fc5bf68acb425cb7f34d11fcf
It was only used in one spot, and incorrectly at that.
MozReview-Commit-ID: EWkkrAlYT7W
--HG--
extra : rebase_source : a19afe8f49e1e0fd430ddbff81978eb3511c5fb5
HasSPS, ExtractExtraData and CompareExtraData have nothing to do with the handling of annex B format. They are raw H264 related methods.
It will also prevent in the following change to have cycling references between two headers.
MozReview-Commit-ID: FCs5aU4GcTU
--HG--
extra : rebase_source : a96fe0c70416d38690b0c2f1dee567b0b025e947