This permits using these functions with non-param types such as AutoTArray.
MozReview-Commit-ID: 3J1bLjgwB9M
--HG--
extra : rebase_source : 897e64b6f1c8d1c8c939a18d2b0813b33bcd8083
The webrtc.org code assumes we will always get a valid decoder for a known payload
type, but this is not true for our builds. This adds a check that we have a valid
decoder before calling IncomingPacket.
MozReview-Commit-ID: GUJR7Qn28vh
--HG--
extra : rebase_source : 6bd5872b59d964c3246708f0e6f549bb74dcc0b3
During my backport of RtpStreamId from webrtc.org, I missed a few
places where RepairedRtpStreamId was used or was not completely
implemented. Also, the webrtc.org code used repairedStreamId,
which is not really correct per the spec (draft-ietf-avtext-rid)
so I fixed all occurances to use the correct repairedRtpStreamId
to avoid confusion later.
The RTP header extensions default IDs for RtpStreamId and
RepairedRtpStreamId were also adjusted to not collide with
PlayoutDelay's default ID.
MozReview-Commit-ID: HSlS8nsKQ29
--HG--
extra : rebase_source : f1bf7fc9ceec22de1c56ef3b7be22fccea01ecdb
This allows sending and receiving arbitrarily (we limit to 1 GiB atm) sized
messages while not relying on the deprecated PPID fragmentation/reassembly
mode. The code already supports the ndata extension but it's not activated,
yet. Without the SCTP ndata extension, a large data channel message will
monopolise the SCTP association. While this is a problem, it is a temporary
solution until the extension is being activated. Keep in mind that every
application that uses data channels currently does fragmentation/reassembly on
application-level and it's unlikely that this will change until the popular
implementations (libwebrtc) implement EOR as well. Moreover, until the WebRTC
API specifies an API that hands over partial messages, doing application-level
fragmentation/reassembly is still useful for very large messages (sadly).
We fall back to PPID-based fragmentation/reassembly mode IFF a=max-message-size
is not set in the SDP and the negotiated amount of SCTP inbound streams is
exactly 256. Other implementations should avoid using this combination (to be
precise, other implementations should send a=max-message-size).
It also changes behaviour of RTCDataChannel.send which now raises TypeError in
case the message is too large for the other peer to receive. This is a
necessity to ensure that implementations that do not look at the EOR flag when
receiving are always able to receive our messages. Even if these
implementations do not set a=max-message-size, we use a safe default value (64
KiB, dictated by the spec) that every implementation should be able to receive,
with or without EOR support.
* Due to the use of explicit EOR, this required some major refactoring of all
send-related and deferred sending functions (which is now a lot less
complex). There's now only one place where `usrsctp_sendv` is being used.
* All data channel messages and DCEP messages will be sent without copying them
first. Only in case this fails (e.g. usrsctp's buffer is full), the message
will be copied and added to a buffer queue.
* Queued data channel messages will now be re-sent fairly (round-robin).
* Maximum message size and the PPID-based fragmentation are configurable using
about:config (media.peerconnection.sctp.force_ppid_fragmentation and
media.peerconnection.sctp.force_maximum_message_size).
* Enable interleaving of incoming messages for different streams (preparation
for SCTP ndata, has no effect until it is enabled).
* Enable interleaving of outgoing messages (disabled if SCTP ndata has not been
negotiated).
* Add pending messages flag to reduce performance impact from frequent calls to
SendDeferredMessages.
* Handle partial delivery events (for cases where a partially delivered message
is being aborted).
* Close a data channel/the connection in case the message is too large to be
handled (this is only applied in cases where the remote peer ignores our
announced local maximum message size).
* Various size_t to uint32_t conversions (message length) and back should be
safe now.
* Remove aUsingDtls/mUsingDtls from DataChannelConnection.
* Set maximum message size in SDP and in the data channel stack.
* Replace implicit NS_ENSURE_*'s with explicit NS_WARN_IF's.
* Add SetMaxMessageSize method for late-applying those signalling parameters
when a data channel has been created before the remote SDP was available.
* Limit remote maximum message size and add a GetMaxMessageSize method for a
future implementation of RTCSctpTransport.maxMessageSize.
MozReview-Commit-ID: FlmZrpC5zVI
--HG--
extra : rebase_source : 54e1b838c788a3abbded4fb32fe7c2788f8a9bc0
Since I am already poking around in ffvpxcommon.mozbuild's CFLAGS, also suppress these clang -Wvisibility and -Wstring-conversion warnings:
media/ffvpx/libavutil/dummy_funcs.c:83:34 [-Wvisibility] declaration of 'struct AVBufferRef' will not be visible outside of this function
media/ffvpx/libavutil/dummy_funcs.c:83:67 [-Wvisibility] declaration of 'struct AVFrame' will not be visible outside of this function
media/ffvpx/libavutil/utils.c:119:26 [-Wstring-conversion] implicit conversion turns string literal into bool: 'char [19]' to '_Bool'
And remove -Wno-logical-op-parentheses because clang does not currently report any -Wlogical-op-parentheses warnings for ffvpx.
MozReview-Commit-ID: 1kEwEHeD1PC
--HG--
extra : rebase_source : 133fa139f5389467919b88b96b8cbbf632bf002d
clang doesn't support gcc warning options -Wdiscarded-qualifiers or -Wmaybe-uninitialized in media/ffvpxcommon.mozbuild (added in bug 1369791), so only suppress those warnings for real gcc.
warning: unknown warning option '-Wno-discarded-qualifiers'; did you mean '-Wno-ignored-qualifiers'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
MozReview-Commit-ID: JUEqa6AN59x
--HG--
extra : rebase_source : 45e3c43d57e58119170700f7a339d1f2dfacff2c
extra : source : ee4a75aeb3585719700e1700746ce55984eba6fa
GYP of WebRTC should reference MOZ_SYSTEM_LIBEVENT values if available.
MozReview-Commit-ID: CshsPrRidM8
--HG--
extra : rebase_source : 9e619c2f49e7c2b3f680814b95b823996773fa6c
libevent uses event.h header that is fuzzy name. Since our in-tree libevent is libevent2, we should use libevent2 headers instead of deprecated event.h
MozReview-Commit-ID: 6DjW9JEkNWL
--HG--
extra : rebase_source : b774e177b137bf7427122253a3e4c698689e08a4
This is basically a cosmetic change; references are the normal way to do string
outparams.
--HG--
extra : rebase_source : ffc5945f269bdcd3d4116755b56713e87a44b6cd
There does not seem to be any bad effects from calling stop twice, so just log that
it has happened rather than throwing an exception.
--HG--
extra : rebase_source : 0d92bad7b33010f50f41de8498b8406c3521c9e7
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
