This reverts commit 1b8ef63876ebfa55a51c8ca9b1d8206bf8233e01.
Reason for revert: Breaks downstream projects. b/155256727
Original change's description:
> Add an optional override for AudioRecord device
>
> This is important when we have multiple named devices connected over
> USB (eg. "Webcam", "Microphone", "Headset") and there is some way to
> choose a specific input device to route from.
>
> Bug: b/154440591
> Change-Id: I8dc1801a5e4db7f7bb439e855d43897c1f7d8bc4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173748
> Commit-Queue: Robin Lee <rgl@google.com>
> Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31130}
TBR=henrika@webrtc.org,sakal@webrtc.org,rgl@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: b/154440591, b/155256727
Change-Id: I6836676096d47d9da5702a40b9d127569ad50dda
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175008
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31238}
This patch adds detection of 5G to andoird_network_monitor
using the TelephonyManager.NETWORK_TYPE_NR.
It also adds
- TelephonyManager.NETWORK_TYPE_GSM as 2G
- TelephonyManager.NETWORK_TYPE_TD_SCDMA as 3G
- TelephonyManager.NETWORK_TYPE_IWLAN as 4G
note: AdapterTypeFromNetworkType still return rtc::ADAPTER_TYPE_CELLULAR
for all cellular connections (changing that is a next step).
Bug: webrtc:11473
Change-Id: If2e681e10b24f46ea0071db0cdba758a8c4e7ee2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174500
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31171}
This is important when we have multiple named devices connected over
USB (eg. "Webcam", "Microphone", "Headset") and there is some way to
choose a specific input device to route from.
Bug: b/154440591
Change-Id: I8dc1801a5e4db7f7bb439e855d43897c1f7d8bc4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173748
Commit-Queue: Robin Lee <rgl@google.com>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31130}
We have observed an internal deadlock in libGLESv2_adreno where one
thread is in eglCreateContext and another thread in glUseProgram. We
have observed similar deadlocks before and started to synchronize all
access to the offending GL functions. Calls to eglCreateContext are
already synchronized, and this CL synchronizes calls to glUseProgram as
well.
Bug: b/153513005
Change-Id: I576e564aab44c9e429f2b1407105ed72942c309e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173742
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31118}
to avoid collission and confusion with VideoCodeType based on
c++ enum with the same name.
Bug: b/148146536
Change-Id: I049cce21d59f454c7ce507fdfc3a85d168f96223
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/170048
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30728}
This makes it safe to deliver frames to the sink from VideoProcessor
even after setSink has been called with null reference without danger
of use after free.
Bug: b/148063550
Change-Id: Ib78f75ac49fc6117f744c55da1a4e671bbdcdf22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168160
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30455}
The current camera switch API sequentially cycles through each
camera name for each method invocation. This policy provides
reasonable behavior for devices with 2 or 3 cameras, but
presents challenges with devices that contain several cameras.
For example in a scenario where the current camera is oriented
on the same side as the next camera name, a developer would need to
call switchCamera multiple times to capture from a camera oriented on
a different side of the device.
This commit allows a developer to specify a camera name when switching
cameras. This flexibility allows developers to have more control over
which device they switch to in cases where a device contains several cameras.
Bug: webrtc:11261
Change-Id: I93d46d70b2c7cf735a411a4ef4f33e926bf3a5ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165040
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30199}
This wires the current degradation preference in the SDK, it will later
be nullable in a follow up change once the native API supports it.
Bug: webrtc:11164
Change-Id: I8324e6e0af996dfddfa07e3aff4ba242d9533388
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161321
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30170}
The NetEqFactory is currently expected to wrap the AudioDecoderFactory,
but this turns out not to be a good idea. Instead, it makes more sense
to pass the AudioDecoderFactory through the CreateNetEq method.
Bug: webrtc:11005
Change-Id: I8027ff6593f40c92072e7e88157631dcf329a984
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160644
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29918}
Implementers of Java wrappers for native encoders need to have the same
implementation of all the unsupported methods, as mentioned in the
documentation of VideoEncoder.createNativeVideoEncoder (and its decoder
equivalent).
This simplifies implementation of such encoders/decoders, and also make sure
they don’t override unsupported methods, as they are guaranteed not to be
called.
Bug: None
Change-Id: Iaa8499eda1b52cc14b04622bea2766cd09ba43e6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160186
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Xavier Lepaul <xalep@google.com>
Cr-Commit-Position: refs/heads/master@{#29866}
Those are preventive annotations to prepare for incoming android update
(coming with Chromium roll).
Currently the roll is blocked partly because errorprone complains!
Bug: webrtc:11095, chromium:1003532
Change-Id: If4e2879a522e895ce7fb1f2a9ad36d06f98f2a61
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160002
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Yves Gerey <yvesg@google.com>
Cr-Commit-Position: refs/heads/master@{#29830}
This CL ensures that webrtc can work with an already-connected Wi-Fi
Direct network on Android Q.
Bug: None
Change-Id: Icf98c2f029fe0a92f95266310e6304268c2d9c70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157504
Reviewed-by: Alex Glaznev <glaznev@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29579}
Intended to be used for holding on to references to the java
EncodedImage and call its release method when no longer used by C++.
Bug: webrtc:9378
Change-Id: I40d917c2bb4217419ef2d609e517566c8466a274
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154740
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29347}
Callback set by HardwareVideoEncoder, and wired to the codec's
releaseOutputBuffer. Intention is to move call of this method to the
destructor of a corresponding C++ class in a followup cl, and
eliminate an allocation and memcpy in the process.
Bug: webrtc:9378
Change-Id: I578480b63b68e6ac7a96cdde36379b3c50f05c3f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142160
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29283}
The performance cost is not trivial but according to my profiling,
it is acceptable.
Bug: b/139745386
Change-Id: I0e63221ccf22e9f6fb32c630ff63a279e765994a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150539
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28973}
The GetImplementations function is similar to the GetSupportedFormats function, but instead of providing one SdpVideoFormat per codec it provides one per codec implementation. These SdpVideoFormats can then be tagged so that a certain implementation can be instantiated when CreateVideoEncoder is called.
Bug: webrtc:10795
Change-Id: I79f2380aa03d75d5f9f36138625abf3543c2339d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145215
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28553}
Encountering GL_OUT_OF_MEMORY is relatively common and we should give
clients a chance to deal with it in a non-fatal way.
Bug: webrtc:8154
Change-Id: Ifa9ca74392f21083692b02a5144dc5632a88d34d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144561
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28495}
