The race occurs if the transport is being destroyed at the same time as
a callback occurs on the usrsctp timer thread (for example, for a
retransmission). Fixed by slightly extending the scope of mutex
acquisition to include posting a task to the network thread, where it's
safe to do further work.
Bug: chromium:1162424
Change-Id: Ia25c96fa51cd4ba2d8690ba03de8af9e9f1605ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202560
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33048}
Functionality wise, there should be no change with this CL, aside
from updating tests to anticipate OnPacketReceived to handle the packet
asynchronously (as already was the case via BaseChannel).
This only removes the network->worker hop out of the BaseChannel
class into the WebRTC MediaChannel implementations. However, it updates
the interface contract between BaseChannel and MediaChannel to align
with how we want things to work down the line, i.e. avoid hopping to
the worker thread for every rtp packet.
The following steps will be to update the video and voice channel
classes to call Call::DeliverPacket on the network thread and only
handle unsignalled SSRCs on the worker (exception case).
Bug: webrtc:11993
Change-Id: If0540874444565dc93773aee89d862f3bfc9c502
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202242
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33040}
This is a reland of 69241a93fb14f6527a26d5c94dde879013012d2a
Fix: The problem was related to NO_MAIN_THREAD_WRAPPING, which
affects https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/rtc_base/thread.cc;l=257-263;drc=7acc2d9fe3a6e3c4d8881d2bdfc9b8968a724cd5.
The original CL didn't attach the definition of the macro
NO_MAIN_THREAD_WRAPPING when building for Chromium (which doesn't have
to be related to //rtc_base anymore but to //rtc_base:threading).
Original change's description:
> Refactor rtc_base build targets.
>
> The "//rtc_base:rtc_base" build target has historically been one of the
> biggest targets in the WebRTC build. Big targets are the main source of
> circular dependencies and non-API types leakage.
>
> This CL is a step forward into splitting "//rtc_base:rtc_base" into
> smaller targets (as originally started in 2018).
>
> The only non-automated changes are (like re-wiring the build system):
> * The creation of //rtc_base/async_resolver.{h,cc} which allows to
> break a circular dependency (is has been extracted from
> //rtc_base/net_helpers.{h,cc}).
> * The creation of //rtc_base/internal/default_socket_server.{h,cc} to
> break another circular dependency.
>
> Bug: webrtc:9987
> Change-Id: I0c8f5e7efe2c8fd8e6bffa0d6dd2dd494cf3df02
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196903
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32941}
Bug: webrtc:9987
Change-Id: I7cdf49d2aac8357f1f50f90010bf2c2f62fa19f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202021
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33001}
This reverts commit 69241a93fb14f6527a26d5c94dde879013012d2a.
Reason for revert: Breaks WebRTC roll into Chromium.
Original change's description:
> Refactor rtc_base build targets.
>
> The "//rtc_base:rtc_base" build target has historically been one of the
> biggest targets in the WebRTC build. Big targets are the main source of
> circular dependencies and non-API types leakage.
>
> This CL is a step forward into splitting "//rtc_base:rtc_base" into
> smaller targets (as originally started in 2018).
>
> The only non-automated changes are (like re-wiring the build system):
> * The creation of //rtc_base/async_resolver.{h,cc} which allows to
> break a circular dependency (is has been extracted from
> //rtc_base/net_helpers.{h,cc}).
> * The creation of //rtc_base/internal/default_socket_server.{h,cc} to
> break another circular dependency.
>
> Bug: webrtc:9987
> Change-Id: I0c8f5e7efe2c8fd8e6bffa0d6dd2dd494cf3df02
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196903
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32941}
TBR=mbonadei@webrtc.org,hta@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
No-Try: True
Bug: webrtc:9987
Change-Id: I1e36ad64cc60092f38d6886153a94f1a58339256
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/201840
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32986}
Higher range of IDs for peer connection has been exhausted.
Adding AV1 to lower range as it was blocking enabling
libaom by default.
This is blocking crrev.com/c/2617229
Bug: chromium:1095763
Change-Id: If5135122954d00cc03afc563071aec99f145140b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/201523
Commit-Queue: Jerome Jiang <jianj@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32967}
The "//rtc_base:rtc_base" build target has historically been one of the
biggest targets in the WebRTC build. Big targets are the main source of
circular dependencies and non-API types leakage.
This CL is a step forward into splitting "//rtc_base:rtc_base" into
smaller targets (as originally started in 2018).
The only non-automated changes are (like re-wiring the build system):
* The creation of //rtc_base/async_resolver.{h,cc} which allows to
break a circular dependency (is has been extracted from
//rtc_base/net_helpers.{h,cc}).
* The creation of //rtc_base/internal/default_socket_server.{h,cc} to
break another circular dependency.
Bug: webrtc:9987
Change-Id: I0c8f5e7efe2c8fd8e6bffa0d6dd2dd494cf3df02
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196903
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32941}
It turned out that the negotiated rtp header extensions are not fully known in WebRtcVideoChannel::AddSendStream.
The cl also remove the unnecessary factory for creating VideoStreamEncoder.
Bug: webrtc:12000
Change-Id: If994c8deb69f3ce4212896d3ad757dac94c6e09f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/198840
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32916}
removes the unused
x-google-port
x-google-max-message-size
which were probably sctp-related and variants of max-message-size
and sctp-port parameters. Similarly for the
protocol
streams
parameters which seem to have been fmtp parameters.
BUG=chromium:943975
Change-Id: I21b543f717d6e12fd737f91c7e159362488cc2e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/198122
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32866}
Two audio channels going into the AudioSource::Sink can either be
down-mixed to mono or encoded as stereo. This change enables WebRTC
users (such as Chromium) to query the number of audio channels actually
encoded. That information can in turn be used to tailor the audio
processing to the number of channels actually encoded.
This change fixes webrtc:8133 from a WebRTC perspective and will be
followed up with the necessary Chromium changes.
Bug: webrtc:8133
Change-Id: I8e8a08292002919784c05a5aacb21707918809c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/197426
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32836}
This is a reland of f08db1be94e760c201acdc3a121e67453960c970
Original change's description:
> Enable FlexFEC as a receiver video codec by default
>
> - Add Flex FEC format as default supported receive codec
> - Disallow advertising FlexFEC as video sender codec by default until implementation is complete
> - Toggle field trial "WebRTC-FlexFEC-03-Advertised"s behavior for receiver to use as kill-switch to prevent codec advertising
>
> Bug: webrtc:8151
> Change-Id: Iff367119263496fb335500e96641669654b45834
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/191947
> Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Ying Wang <yinwa@webrtc.org>
> Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32639}
Bug: webrtc:8151
Change-Id: I36cbe833dc2131d72f1d7e8f96d058d0caa94ff9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195363
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32819}
There is currently an error reported about unsupported formats
for most users when an WebRTC connection is setup. This CL
changes the error to a warning.
The reason is that some H264 profiles are supported in hardware
but not in software. When the decoder is created we will try to
create pair of both software and hardware decoders for the
union of supported formats. The creation of the software
decoder will then fail. There is a small risk that this leads
to errors later but only in rare circumstances. Most of the time
this log line only confuses consumers as well as developers.
Bug: none
Change-Id: Ib2119016fa91bc270437a2bcf7892e9fdd7c419c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196645
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32800}
Without this change, if the user disables QVGA and VGA streams via |active|
flags in SetParamters, the resulting stream would have too high min bitrate.
This would lead to bad performance and low quality adaptation rate.
Bug: none
Change-Id: I919a30bfb248c06747c989afe6965b3afaef2260
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195325
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32706}
In that configuration HAVE_WEBRTC_VIDEO is not defined so null_webrtc_video_engine.h gets included which unlike the real one does not include a required header.
Bug: webrtc:11926, webrtc:12187
Change-Id: I3f9df7a841ea6d9920dcb5b39a7386946c9e4341
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/193784
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32683}
This enables send side bandwidth estimation for audio and removes field
trial "WebRTC-Audio-SendSideBwe" which this was controlled through.
Transport-cc extension still needs to be negotiated.
Bug: webrtc:12222
Change-Id: Ie2268fad13703eeb0f0d38fcf484baaa29715b7c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194142
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32681}
This is a reland of f5e261aaf65cdf2eb903cdf40d651846be44f447
This CL disables RTC_NO_UNIQUE_ADDRESS on MSan builds since
there have been some issues.
Original change's description:
> Introduce RTC_NO_UNIQUE_ADDRESS.
>
> This macro introduces the possibility to suggest the compiler that a
> data member doesn't need an address different from other non static
> data members.
>
> The usage of a macro is to maintain portability since at the moment
> the attribute [[no_unique_address]] is only supported by clang
> with at least -std=c++11 but it should be supported by all the
> compilers starting from C++20.
>
> Bug: webrtc:11495
> Change-Id: I9f12b67b4422a2749649eaa6b004a67d5fd572d8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173331
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32246}
Bug: webrtc:11495, webrtc:12218
Change-Id: I4e6c7cc37d3daffad2407c9a2acfa897fa5b426a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189968
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32668}
- Add Flex FEC format as default supported receive codec
- Disallow advertising FlexFEC as video sender codec by default until implementation is complete
- Toggle field trial "WebRTC-FlexFEC-03-Advertised"s behavior for receiver to use as kill-switch to prevent codec advertising
Bug: webrtc:8151
Change-Id: Iff367119263496fb335500e96641669654b45834
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/191947
Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32639}
This CL does not aim at cleaning up simulcast/SVC configuration, just to make it possible to set the scalability mode for AV1. Implementing a codec agnostic SVC/simulcast API is a (big) project on its own.
Change-Id: Ia88df31eb1111713e5f8832e95c8db44f92887ca
BUG: webrtc:11607
Change-Id: Ia88df31eb1111713e5f8832e95c8db44f92887ca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/192541
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32631}
This can result in a higher max bitrate for the base layer, effectively
causing the minimum bitrate to be 600kbps, which is too high.
Bug: b/173183017
Change-Id: I8b45c1c90ebf10a690420bed79e814f27702a540
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/193702
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32623}
And use it in a few places that were using RTC_CHECK(false) or FATAL()
to do the exact same job. There should be no change in behavior.
Bug: none
Change-Id: I36d5e6bcf35fd41534e08a8c879fa0811b4f1967
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/191963
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32567}
"warning: control reaches end of non-void function [-Wreturn-type]"
Reported by gcc (8.3)
In all the reported cases, the end of function is never actually
reached. Add RTC_CHECK(false) to ensure the compiler is aware that
this path is a dead-end.
Bug: webrtc:12008
Change-Id: I7f816fde3d1897ed2774057c7e05da66e1895e60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189784
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Fabien VALLÉE <fabien.vallee@netgem.com>
Cr-Commit-Position: refs/heads/master@{#32503}
When deinitializing usrsctp, we attempt to call usrsctp_finish in a loop
for three seconds (it may fail because another sctp thread is holding a
reference to something). If the three seconds run out, usrsctp is left
in a still initialized state, and bad things happen down the road if
usrsctp_init is called in the state.
Bug: chromium:1138878
Change-Id: I9c24d51d5a274b06bdf4183261694fc2989136c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189940
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32467}
When processing an INIT for existing SCTP association, which may happen
when transferring to a new remote endpoint, if there are chunks still on
the output queue, an SCTP_SEND_FAILED_EVENT notification will be
delivered while holding the INP lock. When processing this notification,
WebRTC was calling usrsctp_getladdrs in order to look up the
SctpTransport* associated with the socket, but this also tries to
acquire the INP lock, resulting in a deadlock.
The temporary fix is to simply not subscribe to the
SCTP_SEND_FAILED_EVENT notification; it was only used for logging
anyway.
Bug: chromium:1137936
Change-Id: I077efb4c769d6f7855d2fee2d266f19396b16f9d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188502
Commit-Queue: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32427}
This sincludes the SimulcastEncoderAdapter and the
VideoEncoderSoftwareFallbackWrapper. This avoids converting
the frame when that is not needed.
Bug: webrtc:11976
Change-Id: I686725ecfb79c3b8d87d587a907da1602483bfe8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187343
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#32389}
