These tests are very old and come from a time when we tested each method in the
ADM as if the ADM should function as a standalone component.
Several tests are already disabled and we test combinations of APIs that are no
longer valid (since the ADM is now used in a more fixed way in VoE).
The tests does not verify media (we have other tests under
voice_engine/test/auto_test) which starts media and verifies that it works OK.
There are also a a more extensive set of ADM tests for Android and iOS.
You could also say that these tests tests the most "hardware related parts of
the ADM", but not those that we expose via the VoEHardware API.
Hence, not much value to maintain them imo.
NOTRY=TRUE
BUG=webrtc:7250
Review-Url: https://codereview.webrtc.org/2726433003
Cr-Commit-Position: refs/heads/master@{#19522}
Now we always process |rate_profile.num_frames| number of frames.
This means that the output of the tests in
videoprocessor_integrationtest.cc will be slightly different,
as we will no process 300 frames, instead of 299. No rate control
or quality thresholds need to be updated, however.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/3004583002
Cr-Commit-Position: refs/heads/master@{#19515}
The whole point of all the audio codec stuff we've recently published
in api/ is to function as lego bricks so that building stuff like our
builtin audio codec factories will be easy.
(This has landed once before, but got reverted because of Chromium test
failures---apparently, someone isn't ignoring the case of the codec names
like they're supposed to. The quick fix was to preserve the same case
used by the old implementation.)
BUG=webrtc:7821, webrtc:7822
Review-Url: https://codereview.webrtc.org/2998263002
Cr-Commit-Position: refs/heads/master@{#19512}
Adds two new stats to RTCMediaStreamTrackStats:
* totalSamplesReceived is the total number of samples received on
the audio channel and includes real and synthetic samples.
* concealedSamples is the total number of synthetic samples
received on the audio channel used to conceal packet loss.
Bug: webrtc:8076
Change-Id: I36e9828525ec341490cf3310a972b56a8b443667
Reviewed-on: https://chromium-review.googlesource.com/615902
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19506}
The original change https://chromium-review.googlesource.com/c/575315 and
https://chromium-review.googlesource.com/c/590508 have not been well-considered.
So this change reverts part of two changes and adds a
DesktopFrame::set_top_left() function
A DesktopFrame usually contains a very large chunk of memory, which should be
reused as much as possible to reduce the memory allocations. The size of the
memory usually controls by the DesktopFrame::size(). So it's reasonable to const
DesktopFrame::size_: changing it is wrong if the underly buffer is not large
enough.
But DesktopFrame::top_left() is a different story, same as capturer_id,
capture_time_ms and other information in the DesktopFrame, it can be changed to
any value without needing to reconstruct a DesktopFrame instance. So instead of
adding it to the constructor, a DesktopFrame::set_top_left() is added to adjust
the top-left of the DesktopFrame in the entire display coordinate.
After adding DesktopFrame::set_top_left(), we have five variables in a
DesktopFrame which is not initialized in the constructor. For any kind of
wrapper DesktopFrame, say, SharedDesktopFrame and CroppedDesktopFrame, they
needs to copy these five variables after constructing themselves. This is not
convenient and easily to be broken if an implementation forgot to copy them.
So DesktopFrame::MoveFrameInfoFrom() and DesktopFrame::CopyFrameInfoFrom() are
added to the DesktopFrame to help derived classes to copy or move these
variables in one function call.
The difference between MoveFrameInfoFrom() and CopyFrameInfoFrom() is that the
former one uses DesktopRegion::Swap() to move the DesktopRegion from the source
DesktopFrame to this instance, while the later one uses copy-operator to copy
the DesktopRegion from the source DesktopFrame.
So CopyFrameInfoFrom() is usually used when sharing a source DesktopFrame with
several clients. I.e. the source DesktopFrame should be kept unchanged. For
example, BasicDesktopFrame::CopyOf() and SharedDesktopFrame::Share().
On the other side, MoveFrameInfoFrom() is usually used when wrapping a
DesktopFrame. E.g. CroppedDesktopFrame and DesktopFrameWithCursor.
Bug: webrtc:7950
Change-Id: I8b23418960fb681d2ea1f012d1b453f514da2272
Reviewed-on: https://chromium-review.googlesource.com/622453
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19504}
Windows cannot capture contents on VMs hosted in GCE, disable them to unblock
GCE hosting.
Bug: webrtc:8153
Change-Id: Iacdce15008cc092dce36d08b1d5565bbaa5def1f
Reviewed-on: https://chromium-review.googlesource.com/634083
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Commit-Queue: Zijie He <zijiehe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19502}
NetEq network statistics contains discard rate but has not been used and even not been implemented until recently.
According to w3c.github.io/webrtc-stats/#dom-rtcreceivedrtpstreamstats-packetsdiscarded,
this statistics needs to be replaced with an accumulative stats. Such work will be carried out separately.
Meanwhile, we need to add a rate to reflect rate of discarded redundant packets. See webrtc:8025.
In this CL, we replace the existing discard rate with secondary discarded rate, so as to
1. fulfill the requests on webrtc:8025
2. get ready to implement an accumulative statistics for discarded packets.
BUG: webrtc:7903,webrtc:8025
Change-Id: Idbf143a105db76ca15f0af54848e1448f2a810ec
Reviewed-on: https://chromium-review.googlesource.com/582863
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19495}
This CL ensures that the adaptive filter delay is not used for fine
tune echo removal unless the render and capture signals have been
properly aligned.
BUG=webrtc:8189
Review-Url: https://codereview.webrtc.org/3003303002
Cr-Commit-Position: refs/heads/master@{#19492}
This CL robustifies the inaudible echo detection in AEC3 such that a
requirement is that either the render and capture signals are aligned
or that a headset has been detected. This ensures that the inaudible
detection has been able to base the desicion on reliable signals.
BUG=webrtc:8150
Review-Url: https://codereview.webrtc.org/3005503002
Cr-Commit-Position: refs/heads/master@{#19491}
We can't handle no value here anyway and end up setting a default
at each call site. The defaults aren't even the same in each place.
BUG=None
Review-Url: https://codereview.webrtc.org/2998293002
Cr-Commit-Position: refs/heads/master@{#19485}
We are still using cropping window capturer even the window is out of the screen.
See the bug for details.
Bug: webrtc:8134
Change-Id: I5161b1a17a3a1f8244697eea5eb78975be6908f9
Reviewed-on: https://chromium-review.googlesource.com/627338
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19474}
Patch set 1:
Run a script to replace occurrences of WEBRTC_TRACE logging with the new style,
in webrtc/modules/media_file/.
Patch set 2:
- Manually fix log lines not handled by the script
- Update the included headers
- Remove the now unused object ID variables
Bug: webrtc:5118
Change-Id: I1acbaec3fbbdf1deb7b934624a2f1fd38253c7e9
Reviewed-on: https://chromium-review.googlesource.com/602007
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19470}
Bug: webrtc:8105
Change-Id: I751b89194f3fdb10ea41c6f9e48e38edefcbef1a
Reviewed-on: https://chromium-review.googlesource.com/616724
Commit-Queue: Minyue Li <minyue@webrtc.org>
Reviewed-by: Michael T <tschumim@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19469}
Before this change we could crash in Debug when WebRTC audio was first
interrupted and then resumed again. The reason was that the new audio
stream stems from a new native I/O thread and that triggered thread
checkers. With this change, failing thread checkers are detached when
audio is interrupted to ensure that they don't fail when audio is restarted.
NOTRY=TRUE
Bug: webrtc:8126
Change-Id: Ib36ff6bc942477730aba60066f049ed0c43d3901
Reviewed-on: https://chromium-review.googlesource.com/628716
Commit-Queue: Henrik Andreasson <henrika@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19465}
no-unused-lambda-capture was suppressed, but it's been decided as desireable to stop suppressing it. This CL fixes places in the code that trigger it.
1. Some unnecessary captures removed.
2. s/constexpr/const when capturing a float by value - this is good enough to stop the error.
3. Complete removal of the constexpr/const-modifier for int-types as a workaround.
BUG=webrtc:7133
Review-Url: https://codereview.webrtc.org/3005433002
Cr-Commit-Position: refs/heads/master@{#19462}
On Windows a window may be covered by its own child window. So this change also
detects child windows by using EnumChildWindow().
The tooltip or context menu of the child window still cannot be detected after
this change. See bug for details.
Bug: webrtc:8062
Change-Id: I8455a9206d6a1d9da61013ac9debba4d3edae7d8
Reviewed-on: https://chromium-review.googlesource.com/619728
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19457}
This CL ensures that AEC3 recovers more quickly when capture data is
lost in such a manner that the echo path, as seen by AEC3, becomes
noncausal due to the AEC3 buffer misalignment caused by the data loss.
The CL adds the assumption of a minimum echo path delay of 5 blocks
and makes the hysteresis in the delay selection one-sided.
BUG=chromium:757796, webrtc:8131
Review-Url: https://codereview.webrtc.org/2998223002
Cr-Commit-Position: refs/heads/master@{#19454}
Moved the headers video_receive_stream.h and video_send_stream.h from
webrtc/ into webrtc/call/ as part of the Slim and Modular work.
The GN target webrtc:video_stream_api has moved to
webrtc/call:video_stream_api.
There are headers left in webrtc/ with the same name including the
moved headers in webrtc/call/ for not breaking external projects
depending on WebRTC.
At the same time, some minor cleanup is done: Non-pure-virtual functions declared in the two affected headers now have definitions in the same target. After making this change, our 'chromium-style' plugin detected some style violations that have now been fixed: non-inlined constructors and destructors have been added to a number of classes, both inside the GN target of the two affected headers, and in other targets.
BUG=webrtc:8107
Review-Url: https://codereview.webrtc.org/3000253002
Cr-Commit-Position: refs/heads/master@{#19448}
The whole point of all the audio codec stuff we've recently published
in api/ is to function as lego bricks so that building stuff like our
builtin audio codec factories will be easy.
BUG=webrtc:7821, webrtc:7822
Review-Url: https://codereview.webrtc.org/2997713002
Cr-Commit-Position: refs/heads/master@{#19446}
This test is and should be independent of RTP, so we don't need the
information provided in this struct.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2995403002
Cr-Commit-Position: refs/heads/master@{#19443}
Reason for revert:
We are not certain this is the behavior we want.
Original issue's description:
> Fix the video buffer size should take rtt into consideration
>
> BUG=webrtc:8010
>
> Review-Url: https://codereview.webrtc.org/2980413002
> Cr-Commit-Position: refs/heads/master@{#19285}
> Committed: f1e08d0b58TBR=sprang@webrtc.org,gustavogb@gmail.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:8010
Review-Url: https://codereview.webrtc.org/3002033002
Cr-Commit-Position: refs/heads/master@{#19442}
During a period of about one month we have only built with clang and not msvc, and during this period code that does not build with msvc have been submitted.
BUG=webrtc:8122
Review-Url: https://codereview.webrtc.org/2999343002
Cr-Commit-Position: refs/heads/master@{#19433}
* Guard members with a SequencedTaskChecker.
* Intercept encoder/decoder callbacks, and post onto task queue if needed.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2996253002
Cr-Commit-Position: refs/heads/master@{#19428}
The LockManagerOperation global function uses void** which does not work
well with the thread_annotations.h macros and produce compiler warnings
on clang (chromium default). Workarounds to this is hacky and unhelpful
so we disable the analysis for this function, which isn't helpful in
this case anyway.
webrtc_h264_config is no longer needed and is removed.
BUG=8090, 8119
Review-Url: https://codereview.webrtc.org/3000263002
Cr-Commit-Position: refs/heads/master@{#19425}
* Rename some members.
* Shorten visualization file names.
* Make some member functions static, in preparation for moving them
to be helper functions in an anonymous namespace.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/3001193002
Cr-Commit-Position: refs/heads/master@{#19424}
* Make ProcessFrame return void.
* Make |encode_callback_| and |decode_callback_| direct members.
* Remove ::EncodedFrameSize() and ::EncodedFrameType()
* Remove unused |timestamp| member from FrameInfo.
* Reorder printf output from PrintCodecSettings.
* Make some member functions const.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2998063002
Cr-Commit-Position: refs/heads/master@{#19421}
Clang is enabled by default and we currently lack coverage for building on Windows
with MSVC (see crbug.com/757293). This should unblock rolling WebRTC into
Chromium DEPS. We need to improve our trybot coverage for standalone WebRTC
to prevent things like this in the future though (crbug.com/756840).
BUG=webrtc:8119,chromium:756840,chromium:757293
TBR=hbos@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/3003473002
Cr-Commit-Position: refs/heads/master@{#19420}
1) Entering PROBE_RTT when necessary.
2) Congestion window gain of 0.65 instead of constant 4 packets.
3) {1.1, 0.9} pair instead of {1.25, 0.75}
4) Recovery mode.
5) No reaction to losses due to Recovery mode's implementation.
6) Supports encoder.
7) A new test compiling most of the simulation tests.
8) Bucket for high gain phase, disabled by default.
9) Pacer specific to BBR.
BUG=webrtc:7713
Review-Url: https://codereview.webrtc.org/2999073002
Cr-Commit-Position: refs/heads/master@{#19418}
Instead explicitly ignore only the flags we know should be ignored.
BUG=webrtc:7568
Review-Url: https://codereview.webrtc.org/2968003003
Cr-Commit-Position: refs/heads/master@{#19412}
Reason for revert:
iOS workaround.
Original issue's description:
> Revert of quest keyframes more frequently on stream start/decoding error. (patchset #2 id:170001 of https://codereview.webrtc.org/2996823002/ )
>
> Reason for revert:
> Causes iOS H264 calls received in the background to have increased delay before being able to decode stream from sender due to not having a keyframe.
>
> Original issue's description:
> > Reland of quest keyframes more frequently on stream start/decoding error. (patchset #1 id:1 of https://codereview.chromium.org/2994043002/ )
> >
> > Reason for revert:
> > Create fix CL.
> >
> > Original issue's description:
> > > Revert of Request keyframes more frequently on stream start/decoding error. (patchset #1 id:1 of https://codereview.webrtc.org/2993793002/ )
> > >
> > > Reason for revert:
> > > Broke downstream test that was waiting for 5 keyframes to be received within 10 seconds. Maybe the issue is that "stats_callback_->OnCompleteFrame(frame->num_references == 0, ..." was changed to "frame->is_keyframe()"?
> > >
> > > Original issue's description:
> > > > Request keyframes more frequently on stream start/decoding error.
> > > >
> > > > In this CL:
> > > > - Added FrameObject::is_keyframe() convinience function.
> > > > - Moved logic to request keyframes on decoding error from VideoReceived to
> > > > VideoReceiveStream.
> > > > - Added keyframe_required as a parameter to FrameBuffer::NextFrame.
> > > >
> > > > BUG=webrtc:8074
> > > >
> > > > Review-Url: https://codereview.webrtc.org/2993793002
> > > > Cr-Commit-Position: refs/heads/master@{#19280}
> > > > Committed: 26b4804358
> > >
> > > TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,philipel@webrtc.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG=webrtc:8074
> > >
> > > Review-Url: https://codereview.webrtc.org/2994043002
> > > Cr-Commit-Position: refs/heads/master@{#19295}
> > > Committed: 77a983185f
> >
> > TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,deadbeef@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > BUG=webrtc:8074
> >
> > Review-Url: https://codereview.webrtc.org/2996823002
> > Cr-Commit-Position: refs/heads/master@{#19324}
> > Committed: 628ac5964e
>
> TBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,deadbeef@webrtc.org,philipel@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:8074
>
> Review-Url: https://codereview.webrtc.org/2995153002
> Cr-Commit-Position: refs/heads/master@{#19392}
> Committed: 53959fcc2bTBR=terelius@webrtc.org,stefan@webrtc.org,noahric@chromium.org,deadbeef@webrtc.org,tkchin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
BUG=webrtc:8074
Review-Url: https://codereview.webrtc.org/2996153003
Cr-Commit-Position: refs/heads/master@{#19410}
