In later steps the Win/Mac implementation will also be refactored.
The rtc_task_queue target is split up in three separate targets:
rtc_task_queue_api:
Contains the header file task_queue.h but no implementation.
Only external TaskQueue implementations should directly depend on this target.
rtc_task_queue_impl:
Contains the default implementation of task_queue.h.
Only external application targets should directly depend on this target.
rtc_task_queue:
WebRTC targets should depend on this target. It unconditionally depend on rtc_task_queue_api and depending on the new build flag,|rtc_link_task_queue_impl|, depend on rtc_task_queue_impl.
BUG=webrtc:8160
Review-Url: https://codereview.webrtc.org/3003643002
Cr-Commit-Position: refs/heads/master@{#19516}
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}
When adapting a frame, any initial cropping coordinate was replaced
by the coordinate calculated for adapting. Offset initial coordinate
instead.
BUG=webrtc:7880
Review-Url: https://codereview.webrtc.org/2975613002
Cr-Commit-Position: refs/heads/master@{#19509}
RtpVideoStreamReceiver::receive_cs_ is not really necessary, since all of the functions where that lock is acquired, are arrived at from functions of BaseChannel which DCHECK being called from BaseChannel::worker_thread_.
BUG=webrtc:8037
Review-Url: https://codereview.webrtc.org/2987933003
Cr-Commit-Position: refs/heads/master@{#19508}
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}
Clang format wants to put all parameters to WEBRTC_RTCSTATS_IMPL on
their own line, but we prefer to keep the header on the first line and
put the variable arguments (the stats) on their own lines.
Bug: None
Change-Id: Ic53104b46fb3c91c134d524027a150ba10055ad5
Reviewed-on: https://chromium-review.googlesource.com/621409
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19505}
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}
We have been using the Linux way of getting the thread id on Android,
even though we have a special code path for getting it on Android.
BUG=webrtc:8110
Review-Url: https://codereview.webrtc.org/3001333002
Cr-Commit-Position: refs/heads/master@{#19494}
Fixes bug where callback is set to null on reinitialization. Also fixes
a race condition where callback can be null in onTextureFrameAvailable.
BUG=webrtc:8124
Review-Url: https://codereview.webrtc.org/3002093002
Cr-Commit-Position: refs/heads/master@{#19493}
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}
This will help debugging issues with the fallback, in cases where
only LS_WARNING logs are available.
BUG=none
Review-Url: https://codereview.webrtc.org/3007523002
Cr-Commit-Position: refs/heads/master@{#19488}
Add GUARDED_BY annotation to DirectTransport to demonstrate that next_scheduled_task_ is properly protected.
SendRtp(), SendRtcp(), etc., remain as unprotected as they were before the migration from using a thread to using a task-queue.
BUG=webrtc:8113
TBR=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/3002163003
Cr-Commit-Position: refs/heads/master@{#19487}
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}
Testcode updated to use webrtc::test::TempFilename.
Also deletes now unused functions AppleDataDirectory,
AppleTempDirectory and AppleAppName.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2995413002
Cr-Commit-Position: refs/heads/master@{#19483}
also C++ code (see https://bugs.chromium.org/p/webrtc/issues/detail?id=7743
for more information).
We have moved .mm files out of test_support and fileutils (into test_support_objc
and fileutils_objc).
To achieve the goal for run_test and test_renderer (in the next part of the phrase
X is run_test or test_renderer) we have created 2 targets (X_objc and X_generic)
and X will act as a proxy between these targets (this way we can avoid a circular
dependency between X_generic and X_objc).
BUG=webrtc:7743
Review-Url: https://codereview.webrtc.org/2991323003
Cr-Commit-Position: refs/heads/master@{#19479}
Renamed the dtlstransportchannel.h/.cc to dtlstransport.h/.cc which are
the right names for those files because the concept of DtlsTransportChannel
no longer exists.
BUG=None
Review-Url: https://codereview.webrtc.org/3004503002
Cr-Commit-Position: refs/heads/master@{#19478}
Reason for revert:
Fix and reland.
Original issue's description:
> Revert of Modify profiles for H264 encode SW fallback (patchset #2 id:20001 of https://codereview.webrtc.org/2997913003/ )
>
> Reason for revert:
> Breaks the internal bots.
> Root cause: The "public_deps" is defined behind an "if" condition which may not be true.
>
> Original issue's description:
> > Modify profiles for H264 encode SW fallback
> >
> > We have only Constrained Baseline profile available in SW encoder impl
> > so modify the profile to that in case of a fallback
> >
> > BUG=chromium:735959
> >
> > Review-Url: https://codereview.webrtc.org/2997913003
> > Cr-Commit-Position: refs/heads/master@{#19436}
> > Committed: 1fd66656b3
>
> TBR=magjed@webrtc.org,emircan@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:735959
>
> Review-Url: https://codereview.webrtc.org/2995373002
> Cr-Commit-Position: refs/heads/master@{#19438}
> Committed: 296b64eb25TBR=magjed@webrtc.org,zhihuang@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:735959
Review-Url: https://codereview.webrtc.org/2997423002
Cr-Commit-Position: refs/heads/master@{#19476}
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}
This test doesn't actually send/receive any audio; it's only testing
the interface layer. But the fact that it was creating/destroying real
audio devices repeatedly caused problems when tests were run in
parallel. So switching to a fake audio device solves this.
BUG=webrtc:7806
Review-Url: https://codereview.webrtc.org/2997383002
Cr-Commit-Position: refs/heads/master@{#19472}
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}
The field trials enables producing new VideoFrames in camera classes.
This field trial should be enabled if VideoSinks are used.
BUG=webrtc:7749, webrtc:7760
Review-Url: https://codereview.webrtc.org/2984633002
Cr-Commit-Position: refs/heads/master@{#19467}
