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
