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
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
Carsten "Tomcat" Book
Jean-Yves Avenard
Nathan Froyd
Dan Minor
Nicholas Nethercote
Sebastian Hengst
Wes Kocher
Ryan VanderMeulen
Sylvestre Ledru
Michael Froman
Nils Ohlmeier [:drno]
Jan-Ivar Bruaroey
Chris Pearce
Alex Chronopoulos
Alfredo Yang
Andrew McCreight
Andrea Marchesini