Introduce a handle for route created with network emulation layer,
that can be used to remove it in future properly.
Bug: webrtc:10138
Change-Id: I9fb847caeee24333bafb328727711af005b09224
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/127283
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27074}
This required a fairly extensive overhaul:
* Removed locks from the implementation.
The filter/pin architecture does use multiple threads,
but the state is controlled on one and synchronization
is done via flags that don't require locking.
Note though that the baseclasses used a lot of locking, it's unclear why,
but perhaps there are things I'm not aware of. The locking was not done
consistently though, which doesn't seem to have been a problem.
* Change the code to not mix AddRef/Release and use of explicit 'delete'.
* Removed implementations of interfaces we don't need/use.
* Similarly some methods now return E_NOTIMPL.
* Added some utilities to make use of COM interfaces and concepts, easier.
BUG=webrtc:10374
TBR=mbonadei@webrtc.org
Change-Id: Iaedb1157d37ef5d5c75f727dba3d7de75ce22cd8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125086
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Christian Fremerey <chfremer@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27072}
This CL makes the output audio file optional to more
quickly run neteq_rtpplay when no audio output is needed.
The CL also includes necessary adaptations because of pre-existing
dependencies (e.g., the output audio file name is used to create
the plotting script file names).
The command line arguments are retro-compatible - i.e., same behavior
when specifying the output audio file and the new flag
--output_files_base_name is not used.
This CL also includes a test script with which the retro-compatibility
has been verified.
Bug: webrtc:10337
Change-Id: Ie3f301b3b2ed0682fb74426d9cf452396f2b112b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126224
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27067}
This is not used in practice as there's functionality on
other levels that serves the same purpose.
Bug: None
Change-Id: I0488dc42459b07607363eba0f2b06f4c50f7cda4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125520
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27061}
The fuzzer times out on too long inputs.
This CL limits tests to 400 000 bytes, ~ 12 seconds of 8 kHz float audio.
Bug: chromium:940209
Change-Id: I86b772f9d8989a8b129d933d25ece3631a6a365f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126780
Reviewed-by: Alex Loiko <aleloi@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27059}
This fixes an issue where the time between freezes dropped in
perf tests. This was triggered by resetting and updating the bitrates
immediately if the min allocatable bitrate changed, causing a drop in
target bitrate. With this CL, the change in min bitrate will not take
effect until we get more data.
Bug: chromium:940349
Change-Id: Ia680a5f1cfe71847ef90669987e7b89b240b9524
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126625
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27054}
That will avoid linkage error of targets that depend
on global_task_queue_factory without depending on rtc_task_queue
Bug: webrtc:10191
Change-Id: Ia67ea0a3abb715e28160e4e376133cc0309b14e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126621
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27053}
This CL is preparation for extraction of public API for network
emulation layer.
Bug: webrtc:10138
Change-Id: Id59204ea20a103dafce4122c59e51a354836c374
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126624
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27050}
This is a reland after changes to the downstream project
VP9 screenshare is not used currently, and with these values according
to local testing with screenshare_loopback, we get performance not worse than current vp8 settings for similar uplink and downlink values.
Original Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126226
Bug: webrtc:10257
Change-Id: Ib21d7678bd839a3c47457515b0d768c0b979ea40
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126524
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27040}
Before this change the encoder tasks runs on a shared worker queue.
That makes the destruction require synchronization to avoid races.
By keeping a separate encode queue to ChannelSend, we can safely
destruct the object without worrying for left over tasks, as they
will be stopped when the task queue is destroyed.
For TaskQueue implementations using one thread per TaskQueue this
will increase the thread count by the number of AudioSendStreams,
which typically is just one.
This is partly a reland of 9b9344742b186b14d87e827e71a1757f4c94b30e
Original change's description:
> Removes lock from ChannelSend.
>
> The lock isn't really needed as encoder_queue_is_active_ can be checked
> on the task queue to provide synchronization.
>
> There is one behavioral change due to this: We will not cancel any currently
> pending encoding tasks when we stop sending, they will be allowed to finish.
>
> Bug: webrtc:10365
> Change-Id: I2b4897dde8d49bc7ee5d2d69694616aee8aaea38
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125096
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#26963}
Bug: webrtc:10365
Change-Id: Iafb84e25d90ec8639359be80fad65763d08e5719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125740
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27038}
This reverts commit 12abf671fd2028ca249e95bdf0456b15a48136f8.
Reason for revert: Breaks downstream project.
Original change's description:
> Reland "Tune vp9 screenshare bitrate and framerate of spatial layers"
>
> This is a reland without any changes as it seems problems with webrtc-in-chrome importer were flakes or
> caused by some issues within chrome codebase.
>
> Tune vp9 screenshare bitrate and framerate of spatial layers
>
> VP9 screenshare is not used currently, and with these values according
> to local testing with screenshare_loopback, we get performance not worse than current vp8 settings for similar uplink and downlink values.
>
> Original Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126226
>
> Bug: webrtc:10257
> Change-Id: Ie819d8bbab4f14877daac733d162e5ae7ebf2a8e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126460
> Reviewed-by: Johannes Kron <kron@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27036}
TBR=ilnik@webrtc.org,jeroendb@webrtc.org,kron@webrtc.org
Change-Id: I9ad9017b054213f931b3b39c641060d35565f17d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10257
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126523
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27037}
This is a reland without any changes as it seems problems with webrtc-in-chrome importer were flakes or
caused by some issues within chrome codebase.
Tune vp9 screenshare bitrate and framerate of spatial layers
VP9 screenshare is not used currently, and with these values according
to local testing with screenshare_loopback, we get performance not worse than current vp8 settings for similar uplink and downlink values.
Original Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126226
Bug: webrtc:10257
Change-Id: Ie819d8bbab4f14877daac733d162e5ae7ebf2a8e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126460
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27036}
Adding the crypto root directory to WebRTC. The goal with this change is to
centralize the management of crypto code into a single location.
Currently we have cryptography code scattered across pc/ and rtc_base/
which makes it difficult audit and maintain.
By having a crypto/ directory we gain:
1. A clear first point of contact for auditing the cryptography in WebRTC.
2. Fine grain ownership to cryptography maintainers, we can include BoringSSL
maintainers in this directory.
3. It improves maintanability of crypto code as we have improved modularization.
It will not be deeply nested in all different parts of WebRTC.
4. Improved testability. We can cleanly build crypto libraries which plug into
pc/ which we can more easily mock.
5. Enforce stricter rules. For example we may want to enforce ZeroOnFreeBuffer
for all sensitive material. This is easier to enforce in a single directory.
Bug: webrtc:9600
Change-Id: I8e76332c7dcdac0a45a470ba2e930196e1ccf395
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125142
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27028}
This reverts commit aaf3cb3adb618a9f9b14931876b9050201396bee.
Reason for revert: Chrome importer consitently failing after this change
Original change's description:
> Tune vp9 screenshare bitrate and framerate of spatial layers
>
> VP9 screenshare is not used currently, and with these values according
> to local testing with screenshare_loopback, we get performance not worse
> than current vp8 settings for similar uplink and downlink values.
>
> Bug: webrtc:10257
> Change-Id: Icabac04fbd3d616412bbae59291a1fc026d0a504
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126226
> Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Johannes Kron <kron@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27023}
TBR=ilnik@webrtc.org,kron@webrtc.org
Change-Id: I1ef1eeec8fe87a7662a354ef6362b7d463b2bb4c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10257
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126340
Reviewed-by: Jeroen de Borst <jeroendb@webrtc.org>
Commit-Queue: Jeroen de Borst <jeroendb@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27027}
