This uses the VideoAdapter to handle the max-fs constraint rather than
attempting to calculate and enforce it manually within the VideoConduit.
The resolution is taken as the small of the max-fs constraint and the
latest request from the video sink.
The old unit tests for max-fs and max-fr are removed as the size
calculation has now been delegated to the VideoAdapter and the tests do
not verify whether or not video has actually been scaled.
MozReview-Commit-ID: 18khmiNageR
--HG--
extra : rebase_source : 9d4c80ab5d426721c5c409d81130f2a586c862ad
This adds the remaining desktop_capture unit tests with a few exceptions:
app_capturer_unittest does not compile and is not built by webrtc.org,
and desktop_capturer_differ_wrapper_unittest, rgba_color_unittest,
screen_drawer_unittest and test_utils_unittest rely upon code that we do
not build.
--HG--
extra : rebase_source : 6bdac36a46723ade37d6c2ba4a9384ff7205a6e1
Even though we were building the G.722 codec, we weren't setting the
defines so that it would actually be used.
MozReview-Commit-ID: Dw8l2sYwZFA
--HG--
extra : rebase_source : 10cbd61cb483536be32d7b40f1e64222c3259089
The codec mimetype is now shown in the media devtools. May as well make it readable.
MozReview-Commit-ID: 6rccDiTR24m
--HG--
extra : rebase_source : 7b8d1da8f05d0c46d5fd57b5e604ec3aed36a5f2
The codec mimetype is now shown in the media devtools. May as well make it readable.
MozReview-Commit-ID: 6rccDiTR24m
--HG--
extra : rebase_source : 7b8d1da8f05d0c46d5fd57b5e604ec3aed36a5f2
When we build for versions of OS X below 10.8 it is still necessary to
convert from points to pixels when invalidating rectangles as we use the
CGRegisterScreenRefreshCallback and CGRegisterMoveCallback interfaces.
--HG--
extra : rebase_source : cc3a405c1faaf010922b9acbe0edc21da15bb9ac
This edits the third party SCTP library, but upstream has already applied this change to master
MozReview-Commit-ID: ERpMc8EvYZ7
--HG--
extra : rebase_source : cea0d3758275b73a395ad2738edd8eb57c833e1a
In the case of e10s, the ctx flags for default route only (and less
importantly in this case, proxy only) were not set on the ice ctx
when SetStunAddrs was called in PeerConnectionMedia.
MozReview-Commit-ID: CldUpJfaaH3
--HG--
extra : rebase_source : 6223722275d4741519890d4d2b8436b05ca43155
The main difference between Linux and other platforms is that mozglue is
a static library and doesn't include the allocator, while it is a
dynamic library and includes the allocator on other platforms.
As such, linking against mozglue alone doesn't guarantee everything that
should be linked is linked, which GeckoProgram() does. But since
webrtc-gtest doesn't want to link libxul, we use linkage=None.
--HG--
extra : rebase_source : 552b123cb4ef6a861a49bc5eea0f03b9b5427e8b
This removes calls to FATAL() and replaces them with LOG() statements. The
unimplemented functions already returned error codes.
MozReview-Commit-ID: KgXVCIKWoLp
--HG--
extra : rebase_source : 993d3700e734fd6042fc5708261dc58d9987e64b
Currently we apply the scaleResolutionDownBy factor to the resolution
requested by the quality scaler. This can lead to a cycle where the quality
scaler requests a slightly larger resolution and we scale it down even
smaller than the current resolution.
This changes things so that we only apply scaleResolutionDownBy to the
incoming resolution and then take the minimum of the scaled resolution and
the resolution requested by the quality scaler.
--HG--
extra : rebase_source : 1d16ed60b575c48d43e2e1928c518bc197339cbc
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
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
