We use ArrayView in our public API, so its header should be in
webrtc/api/.
BUG=none
Review-Url: https://codereview.webrtc.org/3007763002
Cr-Commit-Position: refs/heads/master@{#19658}
The static method takes a queue name as argument. Used only in one
place, a DCHECK in IncomingVideoStream, which is converted to use
the non-static version of IsCurrent.
BUG=webrtc:8166
Review-Url: https://codereview.webrtc.org/3004873002
Cr-Commit-Position: refs/heads/master@{#19657}
Untracked headers fly under the 'gn check' radar and in the long term
this can cause problems like unnoticed cyclic dependencies.
This cl creates a synthetic target for this header since no other
targets in webrtc/modules/pacing/BUILD.gn seem to be related to it.
BUG=webrtc:7649
NOTRY=True
Review-Url: https://codereview.webrtc.org/2887593003
Cr-Commit-Position: refs/heads/master@{#19656}
This makes it possible for decoder factories to actually provide any
video codec, not just the ones WebRTC knows about. It also brings
the decoder factory interface more in line with that of the encoder
factory.
BUG=webrtc:8140
Review-Url: https://codereview.webrtc.org/3007433002
Cr-Commit-Position: refs/heads/master@{#19654}
Reason for revert:
A few perf tests broken, including
RampUpTest.UpDownUpAbsSendTimeSimulcastRedRtx
RampUpTest.UpDownUpTransportSequenceNumberRtx
RampUpTest.UpDownUpTransportSequenceNumberPacketLoss
Original issue's description:
> Use RtxReceiveStream.
>
> This also has the beneficial side-effect that when a media stream
> which is protected by FlexFEC receives an RTX retransmission, the
> retransmitted media packet is passed into the FlexFEC machinery,
> which should improve its ability to recover packets via FEC.
>
> BUG=webrtc:7135
>
> Review-Url: https://codereview.webrtc.org/3008773002
> Cr-Commit-Position: refs/heads/master@{#19649}
> Committed: 5c0f6c62eaTBR=brandtr@webrtc.org,danilchap@webrtc.org,stefan@webrtc.org,magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/3010983002
Cr-Commit-Position: refs/heads/master@{#19653}
Instead of the longest frame since the last GetStats call, the longest
frame received during last 10 seconds should be returned in GetStats().
Previous way is not a good idea because there are maybe several
consumers of GetStats calls. If not all of them parse timing frame
reports, some of them may be lost.
Also, streamline reporting of TimingFrames via GetStats (remove separate
methods and use VideoReceiveStream::Stats struct instead).
BUG=webrtc:7594
Review-Url: https://codereview.webrtc.org/3008983002
Cr-Commit-Position: refs/heads/master@{#19650}
This also has the beneficial side-effect that when a media stream
which is protected by FlexFEC receives an RTX retransmission, the
retransmitted media packet is passed into the FlexFEC machinery,
which should improve its ability to recover packets via FEC.
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/3008773002
Cr-Commit-Position: refs/heads/master@{#19649}
Changes made:
* VideoProcessorIntegrationTest definition goes in .h file.
* Member function definitions go into .cc file.
* Tests move to _libvpx.cc and _openh264.cc files.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/3008913002
Cr-Commit-Position: refs/heads/master@{#19637}
The SrtpTransport takes the SRTP responsibilities from the BaseChannel
and SrtpFilter. SrtpTransport is now responsible for setting the crypto
keys, protecting and unprotecting the packets. SrtpTransport doesn't know
if the keys are from SDES or DTLS handshake.
BaseChannel is now only responsible setting the offer/answer for SDES
or extracting the key from DtlsTransport and configuring the
SrtpTransport.
SrtpFilter is used by BaseChannel as a helper for SDES negotiation.
BUG=webrtc:7013
Review-Url: https://codereview.webrtc.org/2997983002
Cr-Commit-Position: refs/heads/master@{#19636}
This is good for a few reasons:
- We avoid grabing a lock twice.
- We avoid an unnecessary copy.
- We avoid a race where a packet could potentially be removed before the
second time we call GetCodecHeader.
BUG=None
Review-Url: https://codereview.webrtc.org/3009833002
Cr-Commit-Position: refs/heads/master@{#19635}
Ownership of EglBase is moved to PeerConnectionClient.
BUG=webrtc:8135
Review-Url: https://codereview.webrtc.org/3007893002
Cr-Commit-Position: refs/heads/master@{#19634}
Receive logic in voe::Channel attempted to handle RTX if
RTPPayloadRegistry::IsRtx returns true, but the audio code never calls
the config methods (SetRtxSsrc or SetRtxPayloadType) required for that
to ever happen.
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/3006913002
Cr-Commit-Position: refs/heads/master@{#19633}
This CL contains automatically applied fixes suggested by the
ClangTidy analyzer (http://clang.llvm.org/extra/clang-tidy/). The
following kinds of fixes is present:
* renaming variables when the names in the method signature don't
match the names in the method definition
(ClangTidy:readability-inconsistent-declaration-parameter-name)
* ClangTidy:readability-container-size-empty,
ClangTidy:misc-unused-using-decls,
ClangTidy:performance-unnecessary-value-param,
ClangTidy:readability-redundant-control-flow
This is a 'pilot' CL to check if automatic code analyzers can
feasibly be integrated into the WebRTC infrastructuve.
The renamings have been manually expected for consistency with
surrounding code. In echo_cancellation.cc, I changed several names in
the function implementation to match the function declaration. The
tool suggested changing everything to match the function definitions
instead.
Bug: None
Change-Id: Id3b7ba18c51f15b025f26090c7bdcc642e48d8fd
Reviewed-on: https://chromium-review.googlesource.com/635766
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Alex Loiko <aleloi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19630}
We want to reuse some of this functionality for the new video codec
factories, but not of all it, so this CL refactors out what we want to
reuse to a static function.
BUG=webrtc:7925
Review-Url: https://codereview.webrtc.org/3010743002
Cr-Commit-Position: refs/heads/master@{#19628}
Bug: webrtc:8098
Change-Id: If313c8069a16bfb3c2752dcca7fb1cfca24c1caf
Reviewed-on: https://chromium-review.googlesource.com/643299
Reviewed-by: Michael T <tschumim@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19627}
Problem fixed by this CL: Let DerivedQueuedTask be a custom derivation of QueuedTask. Calling PostTask() with a std::unique_ptr<DerivedQueuedTask> does not work, because overload resolution sees PostTask(const Closure& closure) as a better match. The workaround of explicitly converting to std::unique_ptr<QueuedTask> before calling PostTask() results in less readable code.
Solution: Use std::enable_if to limit the template, thereby making the compiler use the right version of PostTask().
BUG=webrtc:8188
Review-Url: https://codereview.webrtc.org/3006933002
Cr-Commit-Position: refs/heads/master@{#19625}
The millisecond field is deprecated and will be removed once the
dependencies have been updated.
BUG=webrtc:7760
Review-Url: https://codereview.webrtc.org/3010623002
Cr-Commit-Position: refs/heads/master@{#19622}
Per discussion in
https://chromium-review.googlesource.com/c/external/webrtc/+/641814, the
behavior of IsWindowOnScreen() functions when native APIs fail should be
flipped. I.e. window is *not* on screen if OS cannot find it.
Bug: chromium:758554
Change-Id: Ife449a5261fcd89c37595e29a0b1802fcf3c42a5
Reviewed-on: https://chromium-review.googlesource.com/644290
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19617}
This is the first step towards supporting multiple audio/video
channels in PeerConnection/WebRtcSession. For now, there can only
be 0 or 1 channels in the vector. This adds the framework so that
all the other code that assumes a single audio/video channel can
be transitioned one-by-one to multiple channels.
Bug: webrtc:8183
Change-Id: I6456af32d6e3adf7eb83e281e43253ea973c4eb9
Reviewed-on: https://chromium-review.googlesource.com/644222
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19615}
GetCroppingWindowRect() is too generic and easy to be misused. For example, in
WindowCapturerWin, it's used to calculate the DesktopRect of the target window,
which is inaccurate. See the screenshot in the bug, it wrongly crops borders on
Windows 8+.
So GetCroppingWindowRect() should be removed eventually, the logic should be
placed in CroppingWindowCapturerWin. But since it's still used in the deprecated
logic in MouseCursorMonitorWin, I would prefer to remove this function after
MouseCursorMonitor improvement has been finished.
But before that, WindowCapturerWin should use GetWindowDrawableRect() instead of
GetCroppedWindowRect() to avoid the wrongly cropping behavior on Windows 8+.
Bug: webrtc:8157
Change-Id: I012b663dced8105623c563dbe55ffcb8d7f17f75
Reviewed-on: https://chromium-review.googlesource.com/642092
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19614}
As discussed in change
https://chromium-review.googlesource.com/c/external/webrtc/+/634043, the name of
IsWindowMinimized() functions is too confusing. IsWindowOnScreen() is preferred,
since it describes the behavior of the functions more accurately.
This change does not flip the default behavior of these functions to avoid a
behavior change. TODO has been added; and the flipping will happen in a
following change.
Bug: chromium:758554
Change-Id: I009c0fa57142756e5c83f76b2a3561253db1b67f
Reviewed-on: https://chromium-review.googlesource.com/641814
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19613}
Also clarify the ownership of created channels.
Bug: None
Change-Id: I9cbaec177069d27da2b3b48b93af48f705243b4b
Reviewed-on: https://chromium-review.googlesource.com/643950
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19612}
also C++ code (see https://bugs.chromium.org/p/webrtc/issues/detail?id=7743
for more information).
To achieve this we have created 2 targets (desktop_capture_objc and
desktop_capture_generic) and desktop_capture will act as a proxy between these
targets (this way we can avoid a circular dependency between
desktop_capture_generic and desktop_capture_objc).
BUG=webrtc:7743
Review-Url: https://codereview.webrtc.org/2989053002
Cr-Commit-Position: refs/heads/master@{#19607}
* First do all frame processing, then do all rate control
statistics calculations. This means that we only need to
synchronize once.
* Run the VideoProcessor on a task queue, thus supporting Android
HW codecs.
* Add some unit tests for the VideoProcessor.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2997283002
Cr-Commit-Position: refs/heads/master@{#19604}
This CL increases the amount of API call jitter that is allowed in AEC3
without causing resets of AEC3. This increase is now possible, as non-
causal alignments will be detected by the newly imposed delay bound.
BUG=8175
Review-Url: https://codereview.webrtc.org/3012553002
Cr-Commit-Position: refs/heads/master@{#19603}
We were leaking a fragmentation header object on each frame.
BUG=webrtc:8132
Review-Url: https://codereview.webrtc.org/3004013002
Cr-Commit-Position: refs/heads/master@{#19602}
directives in our DEPS files are not needed anymore.
Includes from webrtc/rtc_base are also whitelisted in webrtc/DEPS
so we don't have to whitelist it in all the others DEPS files.
BUG=webrtc:7634
NOTRY=True
Review-Url: https://codereview.webrtc.org/3006583002
Cr-Commit-Position: refs/heads/master@{#19601}
This CL encapsulates the logic for unifying the internal and external
video encoders into a helper class. The purpose is to prepare for
introducing a new video encoder factory interface that inherently
represents all encoders (i.e. both internal and external). A helper
interface EncoderFactoryAdapter is introduced that both the old
WebRtcVideoEncoderFactory and the new factory interface can implement
and serves as common point to leave the rest of the code unchanged.
BUG=webrtc:7925
Review-Url: https://codereview.webrtc.org/3006713002
Cr-Commit-Position: refs/heads/master@{#19600}
