Add implementation of RTC_DCHECK_NOTREACHED equal to the RTC_NOTREACHED.
The new macros will replace the old one when old one's usage will be
removed. The idea of the renaming to provide a clear signal that this
is debug build only macros and will be stripped in the production build.
Bug: webrtc:9065
Change-Id: I4c35d8b03e74a4b3fd1ae75dba2f9c05643101db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237802
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35348}
Instead use `parameters_.config.rtp.ssrcs.size()` directly to make decisions about the number of temporal and spatial layer used.
Bug: none
Change-Id: Icba553178ae7fea281c2c67654c510228d9ab5b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237080
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35299}
Remove analog_level_minimum and analog_level_maximum from
AudioProcessing GainController1 and replace their use with fixed
values 0 and 255, respectively.
Bug: webrtc:12774
Change-Id: Ia4bfe5ed43a65f1587ed67f36bfbb2966b6fdf26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235822
Commit-Queue: Hanna Silen <silen@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35297}
The constants are being made private since no new code should use them.
However, the helper functions sill uses "AV1X" internally for backwards
compatibility.
Bug: webrtc:13166
Change-Id: I0a0cd46f31ca70bb7f395c9b1e9cdb202df11f6e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236680
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35289}
This field is unused within WebRTC, and doesn't seem to
be essential for any existing customers.
If this works well, it will be deprecated and removed.
Bug: none
Change-Id: I96d7485e4d094abfa6a8c3d1e6855834c13dedd7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189680
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35263}
This is somewhat klugey, because it does the same checks at two
different layers in the stack, in different functions, which runs
the risk of making them out of sync. But it solves the immediate
problem.
Bug: chromium:1249753
Change-Id: I2ad96f0cc9499c15540ff6946a409b40df3e3925
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235826
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35259}
Benchmarks will spam a lot of annoying lines because of this.
Bug: webrtc:13288
Change-Id: I1321abafb91baefcaa626a561bee58ca3f321291
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235371
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35225}
When sending a large amount of data, the sender will want to keep the
send buffer full so that the socket can quickly drain it as its able to
put more bytes on the wire.
When trying to send a message and when the send buffer is full, an error
will be returned and the OnError callback will be triggered. In these
situations, this is an expected and handled error and should not be
logged as an error, as it causes confusion.
Bug: chromium:1258225
Change-Id: I3e1feab03f60ba5c41cc524d8d8f066445030d18
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235201
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35204}
This change
- adds new type VideoTrackSourceConstraints expressing min/max FPS
constraints.
- adds new method VideoTrackSourceInterface::ProcessConstraints.
- adds new method VideoSinkInterface<>::OnConstraintsChanged.
- updates AdaptedVideoTrackSource and VideoBroadcaster to forward
the constraints to sinks.
- adds several unit tests for the added functionality.
- and finally, implements OnConstraintsChanged in VideoStreamEncoder.
Chromium will be updated in coming CLs to supply constraints set
through the MediaStream module.
go/rtc-0hz-present
Bug: chromium:1255737
No-Try: true
Change-Id: Iffef239217269c332a1aaa902ddeae2440929e22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235040
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35197}
`a && b` only evaluates b if a is true. `a & b` always evaluates
both a and b. If a and b are of type bool, `&&` is usually what you
want, so clang now warns on `&` when both arguments are of type bool.
In the one case where this fires in webrtc, it isn't important if we
evaluate both branches, so I went with `&&`.
Bug: chromium:1255745
Change-Id: I7fd215778fca62e0d5ca64ab0cf1142942eb7304
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/234600
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35181}
In case if primary encoder can't be instantiated (max number of
instances has reached, for example), use fallback encoder.
Bug: none
Change-Id: I477bdeb7af4dcce50e36b1804ffc6ad2ab004dfd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/234500
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35161}
First CL to try to understand the extent of the cleanup needed in
order to remove -Wno-shadow and follow Chromium on enabling this
diagnostic.
Bug: webrtc:13219
Change-Id: Ie699762da50fe3dbc08b1fd92220962d4b7da86b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233641
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35134}
otherwise the generated codec won't match the preassigned codec
and red will use 96 as payload type, increasing the payload type
congestion in the upper range.
BUG=webrtc:11640
Change-Id: I466ed6d4e025ef116f3099e85855e10493408ab1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233560
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35130}
along the lines of RTX handling but with limited support for missing
fmtp lines because of video/red.
BUG=webrtc:13178
Change-Id: Ia866c0e857da6da2ef1e4b81b51f90f534c7bb83
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231948
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35107}
Prior to this commit, the SCTP association could terminate due to too
many retransmission attempts when there is a long duration of packet
loss. The RTCPeerConnection wouldn't terminate, and when the network
later recovers (possibly using a different ICE candidate), it would be a
RTCPeerConnection with media, but without DataChannels.
This commit will make the dcSCTP library never abort by itself when
there are too many retransmissions. It will also put a cap on the retry
duration so that it will do a retry every three seconds (or lower).
Bug: webrtc:13129
Change-Id: I08162ea20d6a60aa0eae2717966d9a2ddba8fc22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232540
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35061}
Thanks to the elimination of `ExperimentalNs`, there is no need anymore
to pass `webrtc::Config` to build APM.
Hence, `AudioProcessingBuilder::Create(const webrtc::Config&)` is also
removed.
Bug: webrtc:5298
Change-Id: I0a3482376a7753434486fe564681f7b9f83939c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232128
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35025}
On the Android and iOS platforms, occasionally crash when using the SimulcastEncoderAdapter.
The Android platform reverted,
In function `SimulcastEncoderAdapter::EncoderContext::Release`,
After executing `encoder_->RegisterEncodeCompleteCallback(nullptr)`
before execute `encoder_->Release()`
If the encoder thread is executed here,
```
// out/xxx/xxx/gen/sdk/android/generated_video_jni/VideoEncoderWrapper_jni.h
JNI_GENERATOR_EXPORT void Java_org_webrtc_VideoEncoderWrapper_nativeOnEncodedFrame(
JNIEnv* env,
jclass jcaller,
jlong nativeVideoEncoderWrapper,
jobject frame) {
VideoEncoderWrapper* native = reinterpret_cast<VideoEncoderWrapper*>(nativeVideoEncoderWrapper);
CHECK_NATIVE_PTR(env, jcaller, native, "OnEncodedFrame");
return native->OnEncodedFrame(env, base::android::JavaParamRef<jobject>(env, frame)); // HERE
}
```
it will cause `native` to nullptr.
iOS also.
Bug: webrtc:13156
Change-Id: Id5563b3fa2c11606ae7b35de56bbaa6adba59b14
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231780
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34989}
The non-primary SSRC being RTX, for example. Normally a default stream
wouldn't be created from RTX packets, but there is a window of time
where packets can be received before the video engine has receive
parameters/payload type mappings, so it creates one anyway.
Then in AddRecvStream, normally the default stream would be destroyed
before creating a new one, but this only happens for sp.first_ssrc().
Resulting in the error "Receive stream with SSRC 'X' already exists".
Fixed by simply iterating over all SSRCs.
Bug: webrtc:13171
Change-Id: Iaf4e4a3ceafddee3d9b2d1e24af68be56f9695de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231633
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34971}
This is a reland of 9d0730942677a520ce7e184d081b4c5a2469fc48
Original change's description:
> red: generate and parse the red fmtp format
>
> generates a fmtp line like
> a=fmtp:<red payloadtype> <opus payloadtype>/<opus payloadtype>
> and matches the incoming redundant payload types against the
> send codec one. Offers without an FMTP line will not use RED.
> Redundancy levels of 1 (plus main packet ) to 32 are accepted but
> this is not wired up to the encoder since the O/A semantic of
> RFC 2198 is not clear.
>
> This decreases the chance of a collision with the SATIN codec
> which also runs on 48khz (but so far does not specify a channelCount of 2)
>
> BUG=webrtc:11640
>
> Change-Id: I8755e5b1e944d105212f1bbe4f330cf4e0753e67
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229583
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34848}
Bug: webrtc:11640
Change-Id: I9465e489897a8ded9845592477fe14678af7ab61
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230545
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34965}
Setting the rtp header extensions on the packet delivery thread
(currently worker, soon to be network), is now possible without
taking the hit of deleting and recreating the receive stream (and
rtp receiver and related state).
Bug: webrtc:11993
Change-Id: I9bbe306844a25d85d79cd216092ead66eaf68960
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223741
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34953}
In benchmarks, each log statement represent 2% of the CPU usage. RTC_LOG
is not very expensive, but not free either, and it's called for every
received and sent packet.
Bug: webrtc:12943
Change-Id: Id65baafb5e494091a3a7604687718fdd4f477d86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231223
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34929}
This reverts commit 9d0730942677a520ce7e184d081b4c5a2469fc48.
Reason for revert: Speculative revert due to failing downstream test. If the test recovers, I'll assign the issue to the tests owners.
Original change's description:
> red: generate and parse the red fmtp format
>
> generates a fmtp line like
> a=fmtp:<red payloadtype> <opus payloadtype>/<opus payloadtype>
> and matches the incoming redundant payload types against the
> send codec one. Offers without an FMTP line will not use RED.
> Redundancy levels of 1 (plus main packet ) to 32 are accepted but
> this is not wired up to the encoder since the O/A semantic of
> RFC 2198 is not clear.
>
> This decreases the chance of a collision with the SATIN codec
> which also runs on 48khz (but so far does not specify a channelCount of 2)
>
> BUG=webrtc:11640
>
> Change-Id: I8755e5b1e944d105212f1bbe4f330cf4e0753e67
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229583
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34848}
TBR=henrik.lundin@webrtc.org,hta@webrtc.org,philipp.hancke@googlemail.com,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I5a0816a22a2a213679ab047c61e3b1dda40c4f59
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11640
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230140
Reviewed-by: Björn Terelius <terelius@google.com>
Commit-Queue: Björn Terelius <terelius@google.com>
Cr-Commit-Position: refs/heads/main@{#34850}
generates a fmtp line like
a=fmtp:<red payloadtype> <opus payloadtype>/<opus payloadtype>
and matches the incoming redundant payload types against the
send codec one. Offers without an FMTP line will not use RED.
Redundancy levels of 1 (plus main packet ) to 32 are accepted but
this is not wired up to the encoder since the O/A semantic of
RFC 2198 is not clear.
This decreases the chance of a collision with the SATIN codec
which also runs on 48khz (but so far does not specify a channelCount of 2)
BUG=webrtc:11640
Change-Id: I8755e5b1e944d105212f1bbe4f330cf4e0753e67
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229583
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34848}
Setting different number of temporal layers is supported by SimulcastEncodeAdapter and LibvpxVp8Encoder will fallback to SimulcastEncoderAdapter if InitEncode fails.
Bug: none
Change-Id: I8a09ee1e6c70a0006317957c0802d019a0d28ca2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228642
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34785}
Using usrsctp_getladdrs() would sometimes be flagged by TSAN for a lock
order inversion. It was used to retrieve the "id" of the socket on the
transport.
The "id" is instead stored in the "ulp_info" parameter, which is
passed with each callback from usrsctp.
Bug: webrtc:12823
Change-Id: Ifb3d7780273a460e677526dd3a93f9365b29300c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229000
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34784}
