As part of this change, a task queue is used to handle packet
processing in real time mode. This requires that we also do
most call and media stream related operation on the same task
queue to satisfy thread checkers.
Bug: webrtc:10365
Change-Id: Icdd9d56e4ca14f2c944dc655c91e29392e3765f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/127544
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27379}
And delete corresponding dependencies on :webrtc_common. After this
change, common_types.h is included directly only from code in the
following directories:
api/
api/video/
api/video_codecs/
common_video/libyuv/include/
media/base/
modules/remote_bitrate_estimator/
modules/rtp_rtcp/source/
modules/video_coding/codecs/vp9/
There remains plenty of indirect dependencies on the types declared in
common_types.h, but the fewer direct dependencies should make it
easier to find the proper place for each type.
Bug: webrtc:5876
Change-Id: I93e8f214025ecb613c19fdec2015bd3f96c59aae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130501
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27376}
Some NaCl system headers live in a special directory and the
toolchain doesn't propagate the -I compiler flag [2].
A common workaround in Chromium is to use 'public_deps' in order
to propagate //native_client_sdk/src/libraries/nacl_io:nacl_io_include_dirs
one step further in the build graph.
[1] - https://cs.chromium.org/chromium/src/native_client_sdk/src/libraries/nacl_io/
[2] - -Inative_client_sdk/src/libraries/third_party/newlib-extras
Bug: chromium:925028
Change-Id: I5145b80c2ae6969f79fcbfcf93a6b05c8a122746
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129701
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27373}
Functions htonll and ntohll are only available when
NTDDI_VERSION>=NTDDI_WIN8 or INCL_EXTRA_HTON_FUNCTIONS is defined,
instead of assuming this to be true, this CL replaces them with
_byteswap_uint64 [1].
On top of that, the following functions were assuming host to be
little endian on Windows and NaCl:
- htobe16(v)
- htobe32(v)
- be16toh(v)
- be32toh(v)
- htobe64(v)
- be64toh(v)
But it is the application's responsibility to check the host
endianness before calling ntohs, ntohl (and probably also htons and
htonl). See [2], especially: "The ntohs function returns the value
in host byte order. If the netshort parameter is already in host byte
order, then this function will reverse it. It is up to the application
to determine if the byte order must be reversed.".
After this CL, WebRTC should do the right thing based on the value
of WEBRTC_ARCH_{BIG,LITTLE}_ENDIAN.
[1] - https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/byteswap-uint64-byteswap-ulong-byteswap-ushort
[2] - https://docs.microsoft.com/en-us/windows/desktop/api/winsock/nf-winsock-ntohs
Bug: None
Change-Id: I61ca882ad81dd090fd164b0fdfeec64cd088a71d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129901
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Noah Richards <noahric@chromium.org>
Reviewed-by: Yves Gerey <yvesg@google.com>
Reviewed-by: Yves Gerey <yvesg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27371}
It is possible for the fuzzer to just never deliver packets if the packet delay
is set long enough in the RtpReplayer. This is simply fixed by setting an upper
bound. This change is in the test code setup.
Bug: webrtc:10493,chromium:943420
Change-Id: I54f56e1aa7700f1151e0b58a5a53bc789d032c18
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130365
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27369}
Introduces SequenceChecker, merging the functionality of ThreadChecker
and SequencedTaskChecker. Also making the two latter use the former as
the underlying implementation for backwards compatibility.
This allows code that uses thread checker to accept running on a thread
pool backed task queue.
Bug: webrtc:10365
Change-Id: Ifefc4925694f263088a8a095fdf98a2407c62081
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129721
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27365}
Replacing sets of pointers (that will depend on allocation addresses)
with vectors and lists. This allows deterministic execution.
Also doing some cleanup of the task queue configuration, ensuring that
the task queue states is not set outside of actual task queues.
Bug: webrtc:10365
Change-Id: I1fad621c7b1ba0bbb33db8c3bd69cb3a1e212b9c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130460
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27364}
This reverts commit ab65d8aab5fe63619033371fca1ce2711c2c2137.
Reason for revert: Fails video_engine_tests ExtendedReportsEndToEndTest.TestExtendedReportsCanSignalZeroTargetBitrate
https://ci.chromium.org/p/webrtc/builders/ci/Linux%20MSan/18366
Original change's description:
> Fix target bitrate RTCP messages behavior for SVC streams
>
> Before this CL for SVC streams (e.g VP9) still 3 separate RTP_RTCP senders
> were created. The RTCP target bitrate messages were treated as simulcast
> and were split and send for each separate spatial layer in a separate SSRC.
>
> To fix that an svc flag is now wired to VideoSendStream config
> and filled based on the encoder config in WebrtcVideoEngine. This flag is
> used to differentiate between simulcast and SVC mode in RtpVideoSender.
>
> Bug: webrtc:10485
> Change-Id: Ifa01d12a7d4f01fcbe448ad11e0cc39ab2d1df55
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129929
> Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27345}
TBR=ilnik@webrtc.org,nisse@webrtc.org,sprang@webrtc.org
Change-Id: I184f87289d9dccc67de165038d76a5690158a3b5
No-Tree-Checks: True
No-Try: True
Bug: webrtc:10485
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130467
Commit-Queue: Oleh Prypin <oprypin@webrtc.org>
Reviewed-by: Oleh Prypin <oprypin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27355}
In this CL:
- Created static helper function GenericFrameInfo::DecodeTargetInfo to
convert DTI symbols to a list of GenericFrameInfo::OperatingPointIndication.
- Added per frame DTI information for the different stream structures.
Bug: webrtc:10342
Change-Id: I62ff2e9fc9b380fe1d0447ff071e86b6b35ab249
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129923
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27350}
in production code keep using GlobalTaskQueueFactory()
in tests switch to use DefaultTaskQueueFactory directly.
This reverts commit e27ccf9a1681e0e4ff9281f9a18fea357d2bc890.
Reason for revert: addressed the failure with patchset#2
Original change's description:
> Revert "in WebrtcVoiceEngine allow to set TaskQueueFactory"
>
> This reverts commit a39254da593bbdb0b1e072a44827229680afe3ee.
>
> Reason for revert: Tests are failing due to ThreadChecker's called on valid thread.
>
> Original change's description:
> > in WebrtcVoiceEngine allow to set TaskQueueFactory
> >
> > in production code keep using GlobalTaskQueueFactory()
> > in tests switch to use DefaultTaskQueueFactory directly.
> >
> > Bug: webrtc:10284
> > Change-Id: I170274a98324796623089a965a39f0cbb7e281d9
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128878
> > Reviewed-by: Steve Anton <steveanton@webrtc.org>
> > Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#27296}
>
> TBR=danilchap@webrtc.org,steveanton@webrtc.org
>
> Change-Id: I9742e5d0171a94f3840e197c40fdb44523e4963b
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:10284
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129780
> Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
> Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27297}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:10284
Change-Id: I55fd5811c68d04c3e8cf537974496460b38c1d4f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129933
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27348}
Before this CL for SVC streams (e.g VP9) still 3 separate RTP_RTCP senders
were created. The RTCP target bitrate messages were treated as simulcast
and were split and send for each separate spatial layer in a separate SSRC.
To fix that an svc flag is now wired to VideoSendStream config
and filled based on the encoder config in WebrtcVideoEngine. This flag is
used to differentiate between simulcast and SVC mode in RtpVideoSender.
Bug: webrtc:10485
Change-Id: Ifa01d12a7d4f01fcbe448ad11e0cc39ab2d1df55
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129929
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27345}
With visibility restricted to modules/video_coding/.
Also drop some unneeded dependencies on system_wrappers.
Bug: webrtc:3380
Change-Id: If3b64396953a026bede09c9fb5eb06cfc4c29f3a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130104
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27344}
Chromium requires that all code that waits on a sync primitive be
annotated with ScopedAllowBaseSyncPrimitives(ForTesting). Webrtc
already imports ScopedAllowBaseSyncPrimitives.
ScopedAllowBaseSyncPrimitivesForTesting is equivalent but can only
be used in tests and doesn't required adding a friend declaration to
thread_restrictions.h.
Previously, the code that is annotated with
ScopedAllowBaseSyncPrimitivesForTesting in this CL didn't fail because
it ran on a TaskRunner annotated with the deprecated
WithBaseSyncPrimitives() trait (cf.
https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/task_queue_factory_unittest.cc?l=23&rcl=362f3723ac358d932ea2e3af65512a1243697a31).
Change-Id: Id7cfa2ea108870de86dc887458ae783c807791cc
Bug: chromium:889029
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128823
Commit-Queue: Francois Pierre Doray <fdoray@chromium.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27339}
