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
Michael Froman
Ryan VanderMeulen
Dan Minor
Jean-Yves Avenard
Wes Kocher
Alex Chronopoulos
Chris Pearce
Alfredo Yang
Andrew McCreight
Andrea Marchesini
Nils Ohlmeier [:drno]
Christian Holler
Sylvestre Ledru
Nico Grunbaum
Nathan Froyd
Carsten "Tomcat" Book
Kershaw Chang
Tom Ritter
Phil Ringnalda
Nicholas Nethercote
Bill McCloskey