Reason for revert:
Chromium build issues have been resolved.
Original issue's description:
> Revert of Remove all reference to carbon api (patchset #2 id:20001 of https://codereview.webrtc.org/2299633002/ )
>
> Reason for revert:
> Breaks chromium build
>
> Original issue's description:
> > Remove all reference to carbon api
> >
> > BUG=webrtc:6282
> >
> > Committed: https://crrev.com/dbd8b6bec4143c940b2f2ca8cd85c25d17327964
> > Cr-Commit-Position: refs/heads/master@{#14080}
>
> TBR=magjed@webrtc.org,mflodman@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6282
>
> Committed: https://crrev.com/b096aa7fd375a980daab3a986596548ca5de2a1c
> Cr-Commit-Position: refs/heads/master@{#14081}
TBR=magjed@webrtc.org,mflodman@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6282
Review-Url: https://codereview.webrtc.org/2321493002
Cr-Commit-Position: refs/heads/master@{#14125}
Reason for revert:
Downstream build is fixed.
Original issue's description:
> Revert of Ignore Camera and Flip bits in CVO when parsing video rotation (patchset #3 id:80001 of https://codereview.webrtc.org/2280703002/ )
>
> Reason for revert:
> Breaks downstream build.
>
> Original issue's description:
> > Ignore Camera and Flip bits in CVO when parsing video rotation
> >
> > Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
> > set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
> > The Camera and Flip bit is still unimplemented and will just be ignored
> > though.
> >
> > BUG=webrtc:6120
> > R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
> >
> > Committed: f9e1b922ef
>
> TBR=pthatcher@webrtc.org,danilchap@webrtc.org,tommi@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6120
>
> Committed: https://crrev.com/97667c7746282704acccd896e26175decee349c0
> Cr-Commit-Position: refs/heads/master@{#14035}
TBR=pthatcher@webrtc.org,danilchap@webrtc.org,tommi@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6120
Review-Url: https://codereview.webrtc.org/2320913003
Cr-Commit-Position: refs/heads/master@{#14124}
With this CL, the NetEqReplacementInput class handles reordered and
missing packets in a better way than before, by storing the last
confirmed packet size and using that when the next packet size cannot
be calculated.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2319553003
Cr-Commit-Position: refs/heads/master@{#14122}
1. Use of const in all variable declarations where it is possible
2. Variable names and function arguments changed from CamelCase to match code style
3. A few stale comments removed.
4. Chromium clang plugin check added (now possible thanks to kwiberg@'s work on common.h)
5. Disallow constructor macros added.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2294263002
Cr-Commit-Position: refs/heads/master@{#14120}
"WebRTC.Call.BitrateReceivedInKbps"
"WebRTC.Call.VideoBitrateReceivedInKbps"
"WebRTC.Call.AudioBitrateReceivedInKbps"
"WebRTC.Call.RtcpBitrateReceivedInBps"
Reports the average of periodically computed bitrates over a call (2 sec interval). Adds possibility to later modify the stats and use/report the periodic bitrates.
BUG=webrtc:5283
Review-Url: https://codereview.webrtc.org/2303763002
Cr-Commit-Position: refs/heads/master@{#14119}
Avoids reporting a growing delay (i.e. time b/w current time and oldest packet in the pacer).
BUG=webrtc:6253
Review-Url: https://codereview.webrtc.org/2279283002
Cr-Commit-Position: refs/heads/master@{#14118}
RecreateWebRtcStream was checking the "sending_" flag, but wasn't
checking rtp_parameters_.encodings[0].active. As a result, if an
application calls "RtpSender.setParameters(inactive_params)" then later
the stream is recreated due to some change in SDP parameters, the stream
would incorrectly start sending.
R=pthatcher@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2246313002 .
Cr-Commit-Position: refs/heads/master@{#14116}
AudioNetworkAdaptor is supposed to facilitate AudioEncoder to adapt to varying network conditions.
This is the first of a sequence of CLs that are to add one implementation of AudioNetworkAdaptor.
This CL illustrates the interfaces of the AudioNetworkAdaptor.
BUG=webrtc:6303
Review-Url: https://codereview.webrtc.org/2308573002
Cr-Commit-Position: refs/heads/master@{#14115}
Reason for revert:
Resubmit capturer tests
Original issue's description:
> Revert of [WebRTC] A real ScreenCapturer test (patchset #8 id:240001 of https://codereview.webrtc.org/2268093002/ )
>
> Reason for revert:
> ScreenCapturerTest.CaptureUpdatedRegion fails on Win DrMemory Full.
>
> Original issue's description:
> > [WebRTC] A real ScreenCapturer test
> >
> > We do not have a real ScreenCapturer test before. And after CL 2210443002, a new
> > ScreenDrawer interface is added to the code base to draw various shapes on the
> > screen. This change is to use ScreenDrawer to test ScreenCapturer. Besides test
> > cases, some other changes are included,
> >
> > 1. A WaitForPendingPaintings() function in ScreenDrawer, to wait for a
> > ScreenDrawer to finish all the pending draws. This function now only sleeps 50
> > milliseconds on X11 and 100 milliseconds on Windows.
> >
> > 2. A Color structure to help handle a big-endian or little-endian safe color and
> > provide functions to compare with DesktopFrame::data(). Both ScreenDrawer and
> > DesktopFrameGenerator (in change 2202443002) can use this class to create colors
> > and compare with or paint to a DesktopFrame.
> >
> > 3. ScreenDrawer now uses Color structure instead of uint32_t.
> >
> > BUG=314516
> >
> > TBR=kjellander@chromium.org
> >
> > Committed: https://crrev.com/9d1c54ace0dc9f68da0152aa1ded2a8dba0a43ae
> > Cr-Commit-Position: refs/heads/master@{#14058}
>
> TBR=sergeyu@chromium.org,jamiewalch@chromium.org,kjellander@chromium.org,zijiehe@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=314516
>
> Committed: https://crrev.com/4c44202dc348613695a4b529bbd7c9bdab6195ec
> Cr-Commit-Position: refs/heads/master@{#14071}
TBR=sergeyu@chromium.org,jamiewalch@chromium.org,kjellander@chromium.org,asapersson@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=644130
Review-Url: https://codereview.webrtc.org/2313653003
Cr-Commit-Position: refs/heads/master@{#14113}
Methods are named more consistently and have a more consistent
signatures. The call structure of mixing is slightly
simplified. Anonymous participants are also ramped up.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2298163002
Cr-Commit-Position: refs/heads/master@{#14110}
This file defines webrtc::Config which was mostly used by modules/audio_processing. The files webrtc/common.h, webrtc/common.cc and webrtc/test/common_unittests.cc are moved to modules/audio_processing and the few remaining uses of webrtc::Config are replaced with simpler code.
- For NetEq and pacing configuration, a VoEBase::ChannelConfig is passed to VoEBase::CreateChannel().
- Removes the need for VoiceEngine::Create(const Config& config). No need to store the webrtc::Config in VoE shared state.
BUG=webrtc:5879
Review-Url: https://codereview.webrtc.org/2307533004
Cr-Commit-Position: refs/heads/master@{#14109}
There is no clear reason to have them in build_overrides, and
webrtc/build seems to be a better place.
Also, delete build_overrides/webrtc.gni
NOTRY=True
BUG=webrtc:5949
Review-Url: https://codereview.webrtc.org/2309253004
Cr-Commit-Position: refs/heads/master@{#14108}
This CL introduces a new fuzzer target neteq_rtp_fuzzer that
manipulates the RTP header fields before inserting the packets into
NetEq. A few helper classes are also introduced.
BUG=webrtc:5447
NOTRY=True
Review-Url: https://codereview.webrtc.org/2315633002
Cr-Commit-Position: refs/heads/master@{#14103}
Exynos VP8 HW encoder may generate a bitrate which deviates too
much from target value causing frame drops and fps reduction or
BWE stuck at low values.
Add one more option to bitrate adjustment in HW encoder wrapper
which allows to track and dynamicaly scale bitrate used for
codec configuration.
BUG=b/30951236
R=wzh@webrtc.org
Review URL: https://codereview.webrtc.org/2308843002 .
Cr-Commit-Position: refs/heads/master@{#14095}
We hit a fuzzer bug that caused numDecodedBytesLB + numDecodedBytesUB
> lenEncodedBytes, which is obviously bogus. Check for that, and for
the case whhere the UB decoder itself realized that something was
wrong. (The code already makes the corresponding check for the LB
decoder.)
BUG=chromium:637899
Review-Url: https://codereview.webrtc.org/2315693002
Cr-Commit-Position: refs/heads/master@{#14091}
RembStatus moved to RtcpSender unittest where it fits better
Creating remb in Compound/ReducedSize modes already covered by RtcpSender unittests.
Parsing remb already covered by RtcpReceiverTest.ReceivesRemb
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2312853002 .
Cr-Commit-Position: refs/heads/master@{#14088}
These were used in the transition from GN->GYP.
NOTRY=True
BUG=webrtc:5949
Review-Url: https://codereview.webrtc.org/2310973003
Cr-Commit-Position: refs/heads/master@{#14087}
In GYP the define is set when we build with chrome, but it's always set
in GN.
NOTRY=True
BUG=webrtc:6312
Review-Url: https://codereview.webrtc.org/2313913002
Cr-Commit-Position: refs/heads/master@{#14086}
Changed from 10 to 68.
This is to avoid a flake where the limit is exceeded, see
crbug.com/638554. Our performance tests should flag performance
regressions, we shouldn't rely on crashing because the number of
referenced buffers is not tiny to detect this. However, if a really big
number of buffers (>68) are referenced without being dereferenced it is
likely that we have a bug and frames are leaking in which case we can
DCHECK-crash.
BUG=chromium:638554
Review-Url: https://codereview.webrtc.org/2280593002
Cr-Commit-Position: refs/heads/master@{#14084}
If neteq_rtpplay is invoked with the --ssrc option to select packets
matching a specific SSRC, but no matching packets are found, this CL
provides a meaningful error message.
BUG=webrtc:2692
NOTRY=True
TBR=ivoc@webrtc.org
Review-Url: https://codereview.webrtc.org/2318503002
Cr-Commit-Position: refs/heads/master@{#14083}
Reason for revert:
Breaks chromium build
Original issue's description:
> Remove all reference to carbon api
>
> BUG=webrtc:6282
>
> Committed: https://crrev.com/dbd8b6bec4143c940b2f2ca8cd85c25d17327964
> Cr-Commit-Position: refs/heads/master@{#14080}
TBR=magjed@webrtc.org,mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6282
Review-Url: https://codereview.webrtc.org/2316563002
Cr-Commit-Position: refs/heads/master@{#14081}
DirectX capturer won't be able to update the DesktopFrame for the second
ScreenCapturerWinDirectx instance, if AcquireNextFrame() returns timeout or
unchanged error. Current solution uses |last_frame| of the second
ScreenCapturerWinDirectx instance, which also does not contain the updated frame
between this and last AcquireNextFrame() calls. Considering following situation,
(C1: capturer 1, C2: capturer 2, update: screen updated, next AcquireNextFrame()
call will return a new frame, Fx: a frame x)
update -> C2.capture returns F1 -> update -> C1.capture returns F2 ->
C2.capture unchanged
So using F1 to update the last capture frame is not correct, we need to use F2.
Refer to design doc https://goo.gl/hU1ifG for a detail description.
The change also makes DxgiDuplicatorController work with 2+ DesktopFrame queue.
Now TwoDirectxCapturers test can pass.
BUG=314516
Review-Url: https://codereview.webrtc.org/2299663003
Cr-Commit-Position: refs/heads/master@{#14077}
dirty region than the real screen change. A similar behavior may happen on other
platforms with damage notification support. So it's better to have an individual
layer to handle the Differ logic, and remove capturing independent logic out of
each ScreenCapturer* implementation.
So this change does following things,
1. Update differ_block to handle variable height. differ_block_sse2 has been
renamed to differ_vector_sse2.
2. A new ScreenCapturerDifferWrapper implementation to help set
DesktopFrame::updated_region(). It uses an underlying ScreenCapturer to do
the real capture work, and updates the updated region of DesktopFrame returned
from OnCaptureResult function.
3. FakeDesktopCapturer and FakeScreenCapturer to generate controllable
DesktopFrame by using DesktopFrameGenerator and DesktopFramePainter.
4. Test ScreenCapturerDifferWrapper by using FakeScreenCapturer.
After this change, we can eventually remove all Differ logic from
ScreenCapturer* implementations, and fix a potential crash bug in
ScreenCapturerLinux class. It wrongly assumes previous_frame() has a same size
as current_frame(). https://goo.gl/3nSqOC
BUG=633802
TBR=kjellander@webrtc.org
Review-Url: https://codereview.webrtc.org/2202443002
Cr-Commit-Position: refs/heads/master@{#14076}
