The race condition is between ~ScreenCapturerMac and the ScreenRefresh and
ScreenUpdateMove callbacks. The destructor calls
UnregisterRefreshAndMoveHandlers but a callback may still occur after the
destruction of the object.
Rather than passing a pointer to ScreenCapturerMac into the callback, this
adds a separate object which keeps a pointer to ScreenCapturerMac guarded
by a CriticalSection. The destructor sets the ScreenCapturerMac to nullptr.
In the next callback, the handler unregisters the callbacks and deletes
the object.
The downside to this approach is that if the ScreenCapturerMac
object is allocated and deallocated before a callback occurs, the memory
for the separate object will be leaked.
We dynamically allocate the memory we need and abort if OOM.
MozReview-Commit-ID: FMGWbOXoN8P
--HG--
extra : rebase_source : d6a28017b7c261d2c8acf2321cd30266bd8d5a35
The race condition is between ~ScreenCapturerMac and the ScreenRefresh and
ScreenUpdateMove callbacks. The destructor calls
UnregisterRefreshAndMoveHandlers but a callback may still occur after the
destruction of the object.
Rather than passing a pointer to ScreenCapturerMac into the callback, this
adds a separate object which keeps a pointer to ScreenCapturerMac guarded
by a CriticalSection. The destructor sets the ScreenCapturerMac to nullptr.
In the next callback, the handler unregisters the callbacks and deletes
the object.
The downside to this approach is that if the ScreenCapturerMac
object is allocated and deallocated before a callback occurs, the memory
for the separate object will be leaked.
When adding the length check for parsing RtpStreamId, I incorrectly used
the '<=' operator instead of the '>' operator.
MozReview-Commit-ID: 46XZBqWxkBc
--HG--
extra : rebase_source : 6290aeed489770070308aafacad01ce5b63a60a1
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
Update to chromium revision 6e4c388c0117fe408b66fbede91081fb1018c5fe.
Includes cdm::ContentDecryptionModule_9 and cdm::Host_9 definitions,
HDCP definitions, and 10 and 12 bit image format definitions.
MozReview-Commit-ID: bYH3OBSzuT
--HG--
extra : rebase_source : cfc291b3452c2154ecd1ca16a2ece0a5a42f0b5e
The new RtpHeaderExtension handling works better with variable length
header extensions, and the new RtpStreamId implementation takes
advantage of it. This is useful to us because we'll be able to add
MID support using the same mechanism.
MozReview-Commit-ID: 5VYQYvhD5gr
--HG--
extra : rebase_source : 900126e0b136343a2767715b12d906b1dbbabe36
This enables apm logging by setting the apm_debug_dump variable in gyp.mozbuild.
Prior to this change, some files were including apm_data_dumper.h with logging
enabled and some were not.
This also removes the AEC* C interface and calls into webrtc::Trace directly.
Whatever historical reasons for having a C interface into these calls no
longer seems to apply. In addition reserving a buffer for the base file name
and then ensuring it was null terminated caused an ASAN "stack-buffer-overflow"
while testing. This was because it was not handling an empty base file
name properly. This would not normally happen if AEC logging was enabled through
about:webrtc, but it still seems safer to use std::string.
MozReview-Commit-ID: Ikz5xO74syA
--HG--
extra : rebase_source : 8e0c59117135fadb75f4a7e6be5588af1404533d
Update to chromium revision 6e4c388c0117fe408b66fbede91081fb1018c5fe.
Includes cdm::ContentDecryptionModule_9 and cdm::Host_9 definitions,
HDCP definitions, and 10 and 12 bit image format definitions.
MozReview-Commit-ID: bYH3OBSzuT
--HG--
extra : rebase_source : d062d233c9a2b59aa5ae5c6e0584ed13b7c83e6e
This provides the abilty to use the PlatformDecoderModule interface, including hardware accelerated ones.
Code is disabled by default via the media.navigator.mediadatadecoder_enabled preference.
MozReview-Commit-ID: 7bWJXEK8CoO
--HG--
extra : rebase_source : df3801c02d3ea6e4c120a4836c4893e18e37d694
Do not only rely on the dimensions retrieved via FrameSizeChange. Both the webrtc::VideoFrameBuffer object and layers::Image know about their dimensions.
We still need to keep the FrameSizeChange mechanism so that the attached media element know about its size before a frame is ready to be displayed.
We will revisit this problem later.
Additionally, don't assume that the frame's stride is the same as the frame's width. It may be true with the software decoders currently used, but it's not the norm.
MozReview-Commit-ID: BTY8lImoUbc
--HG--
extra : rebase_source : 83b07fe030bc19de89d5b5cc52a561fcf096be4d
The methods using it aren't re-entrant. A mutex will do.
MozReview-Commit-ID: TIAL7Itp5A
--HG--
extra : rebase_source : 28e106b0bd7026a36b746d30b57896a5ed74bfa7
This object isn't used and we can use the NativeHandle interface instead to pass this information.
MozReview-Commit-ID: ApMeQfJtZNJ
--HG--
extra : rebase_source : d9ea002a17eb712fb6b9c221739ff4da467fd04f
This platform is no longer support, and it could never have worked anyway.
MozReview-Commit-ID: 8qkVqQB07l8
--HG--
extra : rebase_source : 07d7f87cd133580e5e5461f7910aa848922f973a
We detect when a PSSH is contained in a MOOF and stash them in the
mp4_demmuxer::Moof object. When the mp4_demuxer::SampleIterator returns a
sample, we check whether it's the first sample from its MOOF, and if so, we
attach any PSSH boxes from that MOOF to the sample. The TrackBuffersManager
checks samples upon demux, to see whether they have any EME init data attached,
and if so dispatches thoses to the HTMLMediaElement in 'encrypted' events.
MozReview-Commit-ID: F8GobKOr96F
--HG--
extra : rebase_source : 5366f1008979605aa8fc80216cd1d9cc2eefd346
This removes the disabled TestDummyVideoWithTransport. It was disabled because
it was too flaky to run in automation. It is now broken locally as well due to
threading changes. Given that we can test whether the VideoConduit sends video
well enough in mochitests, I don't see any reason to invest time in fixing it
here, given that it is unlikely to work well in automation anyway.
This also rewrites the MaxFs tests to avoid sending a frame as that results in
a shutdown hang when run in automation.
I have checked that the TestDummyAudioWithTransport continues to work locally,
but I've left it disabled.
MozReview-Commit-ID: AmmUuATxAJa
--HG--
extra : rebase_source : 6416dfff78bc56d0fde131fd1eee40a7dfd597d5
Currently we calculate the stride prior to calculating the scaled dimensions
which results in garbage video when scaling the input frame. This recalculates
the stride based upon the scaled dimensions.
MozReview-Commit-ID: BwOlFwzqdco
--HG--
extra : rebase_source : df9aab6dea81055ca557ba9ea0a9700f7347f389
extra : amend_source : 79e14700aeb5975f6303bc021d62c7f322d298db
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
Rust expect() is bad in C callbacks. Replace TryFrom() with
from_bits_truncate() to drop any unknown PulseAudio flags.
MozReview-Commit-ID: 4RWFB5iGW6Z
--HG--
extra : rebase_source : 3b05d52ae1295825b4857c41135ff08029ad280c
They can change from one SPS to the next, causing unecessary reconstruction of the decoder.
MozReview-Commit-ID: IhCnLuzGc2i
--HG--
extra : rebase_source : b292c658098c378b0a6774f0f559a7b55e4903f6
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 : 022e7a011e3929846f00d1be6590f3ea1c697e7c
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 : 524316ba61ffff1549a0828685ac657abe687426
We will use them to simplify the parsing of the extradata.
MozReview-Commit-ID: 5M5uGXAkkFb
--HG--
extra : rebase_source : e83c8995ebbc60359029f15334e91baaeb098bbd
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 : e28a8230fce4c0f361c4747fce342667d84bff45
It was only used in one spot, and incorrectly at that.
MozReview-Commit-ID: EWkkrAlYT7W
--HG--
extra : rebase_source : 9c719bbf668eafaac0415580ffdfa0cea0942673
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 : b204723cdbb599d4f0a227871ed28f5da39e9cff
The configuration object is spelled with capitals. We didn't
try to build this code on Windows previously, so short-circuit
evaluation saved us from hitting the mistake.
MozReview-Commit-ID: FCGtHW8Dzlw
--HG--
extra : rebase_source : 70676bd436211aa65c7ea447b4aab4bbab61c27a
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
Also moving RID (StreamID) storage to the stack to clear up the TODO item
and simplify the code.
When unset the StreamID is stored as an empty string.
Added missing GUARDED_BY on rid_
Added a check to shortcut checking strlen on the StreamId when it is an empty string (which is most of the time).
MozReview-Commit-ID: EPUlPNBXYsQ
--HG--
extra : rebase_source : 08e1b9ea796c991d141164424014d2311ff9341c
New upstream release with only minor cleanup after 1.2-rc1.
- Speech quality improvements especially in the 12-24 kbit/s range
- Improved VBR encoding for hybrid mode
- More aggressive use of wider speech bandwidth, including fullband speech
starting at 14 kbit/s
- Music quality improvements in the 32-48 kb/s range
- More optimizations for x86 (SSEx) and ARM Neon
- Support for directly encoding packets up to 120 ms
- DTX support for CELT mode
- SILK CBR improvements
- Support for all of the fixes in draft-ietf-codec-opus-update-04 (the mono
downmix and the folding fixes need --enable-update-draft)
- Many bug fixes, including integer overflows discovered through fuzzing
(no security implications)
MozReview-Commit-ID: CDVdiu3R4qT
--HG--
extra : rebase_source : df73c8f7b86043237af16947d0fde12d81c122f4
media/mtransport/test/ice_unittest.cpp:353:12 [-Wunused-member-function] unused member function 'Stream'
media/mtransport/test/ice_unittest.cpp:1394:7 [-Wunused-member-function] unused member function 'trickled'
media/mtransport/test/ice_unittest.cpp:1867:8 [-Wunused-member-function] unused member function 'SetExpectedTypes'
media/mtransport/test/transport_unittests.cpp:917:8 [-Wunused-member-function] unused member function 'InitIce'
MozReview-Commit-ID: 70PNtdc92mg
--HG--
extra : source : 5dc220c3efd5bd2f8f844eb85887a4bcfabb3990
extra : intermediate-source : 0751fb1b9b19a8451c5aba7e021bcb386962ce5d
media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp:181:3 [-Wunused-member-function] unused member function 'operator (anonymous namespace)::JSErrorResult &'
And suppress -Wcomma warnings in upstream webrtc code:
media/webrtc/trunk/webrtc/modules/audio_coding/neteq/background_noise.h:98:22: warning: possible misuse of comma operator here [-Wcomma]
media/webrtc/trunk/webrtc/modules/desktop_capture/differ_unittest.cc:187:22: warning: possible misuse of comma operator here [-Wcomma]
MozReview-Commit-ID: FVecnczsWk7
--HG--
extra : source : a651d94c9adcd64690a6acba4629cf7e1b299e3c
extra : intermediate-source : d5cdb25590475e306cdb8b9766a237e22940f7fa
