Rtcp sender now take smaller interface making it possible to simplify the fake
BUG=webrtc:8016
Review-Url: https://codereview.webrtc.org/2984283002
Cr-Commit-Position: refs/heads/master@{#19181}
Previously, the matrix in VideoFrame was used to crop and scale the
frame. This caused complications because webrtc::VideoFrame doesn't
include a matrix. cropAndScale method is added to VideoBuffer class for
cropping and scaling instead.
BUG=webrtc:7749, webrtc:7760
Review-Url: https://codereview.webrtc.org/2990583002
Cr-Commit-Position: refs/heads/master@{#19179}
I don't think this line could never conceivably fail - if the ctor has reached that point, the object fit in memory, and its members have all been allocated legal memory addresses, none of which may be 0x00.
BUG=None
Review-Url: https://codereview.webrtc.org/2989813002
Cr-Commit-Position: refs/heads/master@{#19176}
This will result in the ipsec interfaces being prioritized below Wi-Fi
and cell interfaces. This makes the most difference when we hit the
default limit for IPv6 interfaces (5), and there are lots of ipsec
interfaces for whatever reason, resulting in the "real" interfaces that
would actually succeed not being used. See the linked bug 7703.
BUG=webrtc:7703, webrtc:3149
Review-Url: https://codereview.webrtc.org/2985133002
Cr-Commit-Position: refs/heads/master@{#19175}
Chromium has adopted Opus 1.2.1 which allows 120ms frame encoding. It
is time to turn on the switch for building WebRTC with this feature.
Bug: webrtc:8042
TBR: kjellander@webrtc.org
Change-Id: I644b47cfb56f835695ef1263741cda6e3ee3d862
Reviewed-on: https://chromium-review.googlesource.com/586725
Commit-Queue: Minyue Li <minyue@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Felicia Lim <flim@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19173}
CreateCroppedDesktopFrame() does not need to create a CroppedDesktopFrame if the
size won't change.
Bug: webrtc:8039
Change-Id: Ie6789a4b473b69bced94c4a25a68f1da6bb3510e
Reviewed-on: https://chromium-review.googlesource.com/587808
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19163}
We should record the number of fallbacks and blank frames.
Bug: webrtc:8040
Change-Id: I92e7b7d7b4664fee6d6bd636609e80e532aa4bd4
Reviewed-on: https://chromium-review.googlesource.com/587688
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19161}
This allows an application to easily override the default limit
(currently 5).
Also adding a test that covers more of the
PeerConnection<->PortAllocator interaction.
BUG=webrtc:7703
Review-Url: https://codereview.webrtc.org/2985653003
Cr-Commit-Position: refs/heads/master@{#19160}
Relanding because the broken chromium test has been fixed:
https://chromium-review.googlesource.com/582196
This CL moves the responsibility for restricting the number of IPv6
interfaces used for ICE to BasicPortAllocator. This is the right place
to do it in the first place; it's where all the rest of the filtering
occurs. And NetworkManager shouldn't need to know about ICE limitations;
only the ICE classes should.
Part of the reason I'm doing this is that I want to add a
"max_ipv6_networks" API to RTCConfiguration, so that applications can
override the default easily (see linked bug). But that means that
PeerConnection would need to be able to call "set_max_ipv6_networks" on
the underlying object that does the filtering, and that method isn't
available on the "NetworkManager" base class. So rather than adding
another method to a place it doesn't belong, I'm moving it to the place
it does belong.
In the process, I noticed that "CompareNetworks" is inconsistent with
"SortNetworks"; the former orders interfaces alphabetically, and the
latter reverse-alphabetically. I believe this was unintentional, and
results in undesirable behavior (like "eth1" being preferred over
"eth0"), so I'm fixing it and adding a test.
BUG=webrtc:7703
Review-Url: https://codereview.webrtc.org/2983213002
Cr-Original-Commit-Position: refs/heads/master@{#19112}
Committed: ad9561404c
Review-Url: https://codereview.webrtc.org/2983213002
Cr-Commit-Position: refs/heads/master@{#19159}
This change returns translated position in the newly added overload
MouseCursorMonitor::Callback::OnMouseCursorPosition(DesktopVector) callback.
Meanwhile it also reduces the duplicate logic in Windows capturer
implementations. So except for the deprecated logic in MouseCursorMonitorWin,
all GetSystemMetrics() function calls are merged into GetScreenRect(),
GetFullscreenRect() and GetFullscreenTopLeft() functions.
Bug: webrtc:7950
Change-Id: Ic2a85a80b6947367bdd20d8f96f11e0f5c269006
Reviewed-on: https://chromium-review.googlesource.com/581951
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Zijie He <zijiehe@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19157}
When you create multiple "PeerConnectionFactory"s, they end up using
the same NetworkMonitor singleton. But the second one's
"AndroidNetworkMonitor" class (in C++) wasn't getting the expected
network list update, and as a result it wasn't binding sockets to
networks successfully, acting as if the networks didn't exist.
The solution is just to move "updateActiveNetworkList" to
"startMonitoring". This CL also does some other minor
cleanup/refactoring, and fixes a more corner-casey issue where, if the
first PeerConnection is destroyed, the second one would stop receiving
network updates.
BUG=webrtc:7946
Review-Url: https://codereview.webrtc.org/2990693002
Cr-Commit-Position: refs/heads/master@{#19156}
There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
- Such a class belongs in sequence_number_util.h.
- It is a cleaner implementation since we can use the rest of
sequence_number_util.h functionality.
- You can choose at which number the unwrapped sequence should start,
which is used to avoid the edge case when a backward wrap can happen
as the first few numbers are unwrapped.
- This unwrapper can unwrap numbers that does not wrap 8/16/32 bits.
BUG=None
Review-Url: https://codereview.webrtc.org/2977603002
Cr-Commit-Position: refs/heads/master@{#19154}
This CL was modified from work of sharifferdous@ (intern supervised by lliuu@)
BUG=webrtc:7389
Review-Url: https://codereview.webrtc.org/2987723002
Cr-Commit-Position: refs/heads/master@{#19146}
This CL ensures that any previously set nondefault settings in the
audio processing module are not overwritten by the ApplyOptions
method in WebRtcVoiceEngine
BUG=webrtc:8018
Review-Url: https://codereview.webrtc.org/2985633002
Cr-Commit-Position: refs/heads/master@{#19144}
During a call, with both phones in horizontal or landscape mode, rapidly switching between the front and back camera sometimes causes the remote video to be shown upside down.
There seems to be a race condition when setting the rotation based on the orientation of the device and which camera we're using.
So use the active input's camera to check instead of the client state.
BUG=webrtc:7898
Review-Url: https://codereview.webrtc.org/2964703002
Cr-Commit-Position: refs/heads/master@{#19139}
Compose them while creating sr/rr instead of presaving in temporary
member variable
BUG=webrtc:5565, webrtc:8016
Review-Url: https://codereview.webrtc.org/2979413002
Cr-Commit-Position: refs/heads/master@{#19138}
The critical-section's scope can be shrunk (we can hold the lock for a shorter time).
BUG=None
Review-Url: https://codereview.webrtc.org/2984973002
Cr-Commit-Position: refs/heads/master@{#19137}
Reason for revert:
Relanding after fixing issues with no video.
Original issue's description:
> Revert of Injectable Obj-C video codecs (patchset #2 id:370001 of https://codereview.webrtc.org/2979983002/ )
>
> Reason for revert:
> Still having problems with no video. Reverting.
> Once no video is visible, no video is available from then on even if the callee app is in the foreground.
>
>
> Original issue's description:
> > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2979973002/ )
> >
> > Reason for revert:
> > Fix the broken build file
> >
> > Original issue's description:
> > > Revert of Injectable Obj-C video codecs (patchset #3 id:400001 of https://codereview.webrtc.org/2981583002/ )
> > >
> > > Reason for revert:
> > > Breaks bots. Build file incorrect.
> > >
> > > Original issue's description:
> > > > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ )
> > > >
> > > > Reason for revert:
> > > > New CL for fixing the issues
> > > >
> > > > Original issue's description:
> > > > > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
> > > > >
> > > > > Reason for revert:
> > > > > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future.
> > > > >
> > > > > Original issue's description:
> > > > > > Injectable Obj-C video codecs
> > > > > >
> > > > > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
> > > > > > (wrapping the VideoToolbox codec).
> > > > > >
> > > > > > Some notes / things left to do:
> > > > > > - There are some hard-coded references to codec types that are supported by
> > > > > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
> > > > > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
> > > > > > These types would need to be more codec agnostic to avoid this.
> > > > > > - Most interfaces are borrowed from the design document for injectable
> > > > > > codecs in Android. Some data in the corresponding C++ classes is discarded
> > > > > > when converting to the Obj-C version, since it has fewer fields. I have not
> > > > > > verified whether all data that we do keep is needed, or whether we might be
> > > > > > losing anything useful in these conversions.
> > > > > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
> > > > > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
> > > > > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
> > > > > > Decoder wrapper classes.
> > > > > > - List the injected codec factory's supported codecs in the list of codecs in
> > > > > > AppRTCMobile.
> > > > > >
> > > > > > BUG=webrtc:7924
> > > > > > R=magjed@webrtc.org
> > > > > >
> > > > > > Review-Url: https://codereview.webrtc.org/2966023002 .
> > > > > > Cr-Commit-Position: refs/heads/master@{#18928}
> > > > > > Committed: a0349c138d
> > > > >
> > > > > TBR=magjed@webrtc.org,andersc@webrtc.org
> > > > > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > > > > BUG=webrtc:7924
> > > > > NOTRY=true
> > > > >
> > > > > Review-Url: https://codereview.webrtc.org/2975963002
> > > > > Cr-Commit-Position: refs/heads/master@{#18979}
> > > > > Committed: 1095ada7ad
> > > >
> > > > R=magjed@webrtc.org
> > > > TBR=tkchin@webrtc.org
> > > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > > NOPRESUBMIT=true
> > > > NOTREECHECKS=true
> > > > NOTRY=true
> > > > BUG=webrtc:7924
> > > >
> > > > Review-Url: https://codereview.webrtc.org/2981583002 .
> > > > Cr-Commit-Position: refs/heads/master@{#19002}
> > > > Committed: a5f1de1e65
> > >
> > > TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,andersc@webrtc.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG=webrtc:7924
> > >
> > > Review-Url: https://codereview.webrtc.org/2979973002
> > > Cr-Commit-Position: refs/heads/master@{#19004}
> > > Committed: 81d40ee149
> >
> > TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,sprang@webrtc.org
> > BUG=webrtc:7924
> >
> > Review-Url: https://codereview.webrtc.org/2979983002
> > Cr-Commit-Position: refs/heads/master@{#19005}
> > Committed: 732a3437da
>
> TBR=magjed@webrtc.org,tkchin@webrtc.org,sprang@webrtc.org,haysc@webrtc.org,andersc@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:7924
>
> Review-Url: https://codereview.webrtc.org/2980173002
> Cr-Commit-Position: refs/heads/master@{#19036}
> Committed: 860f729816TBR=magjed@webrtc.org,tkchin@webrtc.org,sprang@webrtc.org,haysc@webrtc.org,andersc@webrtc.org,jtteh@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7924
Review-Url: https://codereview.webrtc.org/2977213002
Cr-Commit-Position: refs/heads/master@{#19135}
use (already supported) nullptr as indication for no statistics
BUG=webrtc:8016
Review-Url: https://codereview.webrtc.org/2983363002
Cr-Commit-Position: refs/heads/master@{#19129}
"error: values of type 'NSInteger' should not be used as format arguments; add an explicit cast to 'long' instead"
Casting to long is already a common practice in the code base.
This has been blocking the Chromium roll which contains an update to clang 6.0.0
BUG=None
Review-Url: https://codereview.webrtc.org/2987693002
Cr-Commit-Position: refs/heads/master@{#19127}
There is an inconsistency in behavior of PeerConnection.
When I remove track from PeerConnection observer->OnRenegotiationNeeded is called, however if I remove track from MediaStream then there is no notification to renegotiate.
This patch adds missing OnRenegotiationNeeded calls.
BUG=webrtc:7966
Review-Url: https://codereview.webrtc.org/2977493002
Cr-Commit-Position: refs/heads/master@{#19125}
These traces will be traced instead when getStats()
is called by JavaScript.
BUG=chromium:653087
Review-Url: https://codereview.webrtc.org/2972393002
Cr-Commit-Position: refs/heads/master@{#19124}
when creating RtpRtcp module for video send stream.
BUG=webrtc:8016
Review-Url: https://codereview.webrtc.org/2979363002
Cr-Commit-Position: refs/heads/master@{#19122}
We currently don't close the peerconnection before deallocing. That
could potentially cause race conditions if it's still being processed on
other threads.
BUG=webrtc:7976
Review-Url: https://codereview.webrtc.org/2976983002
Cr-Commit-Position: refs/heads/master@{#19121}
