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}
This is tested by a simple unit test and a new fuzzer that verify that all that can be parsed also can be written.
Bug: webrtc:12000
Change-Id: I461aedf97d3dec6e8916e72110fa097c3b31c27f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231642
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34986}
This is done by not adding missing packets to the NACK list if the number of samples per packet is too large.
Bug: webrtc:10178
Change-Id: If46398d6d05ea35f30d7028040d3b808559e950b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231841
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34984}
The documentation for `OpenPipeWireRemote()` says:
> Open a file descriptor to the PipeWire remote where the camera nodes
> are available. The file descriptor should be used to create a
> pw_core object, by using pw_context_connect_fd.
In `InitPipeWire()` we already successfully requested the FD, but then
went on and used the unrestricted default socket.
This does not matter in non-sandboxed environments, as the stream we
want to use is available from both FDs. In flatpak sandboxes, however,
this requires to give full Pipewire access to the application.
Fix this by simply using the right, restricted FD, and while on it,
also make sure to not leak it.
This change has already landed in downstream in Firefox, see
https://phabricator.services.mozilla.com/D122904https://phabricator.services.mozilla.com/D124508
Bug: webrtc:13152
Change-Id: I3f8995c54c797e1a90a980f231e496a13cbe65b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230803
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34983}
The VP9 encoder may drop a frame internally which will not advance the
frame pattern. Consider the following scenario where only spatial layer
0 and temporal layer 0 is active:
1. Key frame encoded
2. Spatial layer 1 is activated
3. Delta T0 dropped
4. Delta T0 encoded
No S1T0 frame is encoded in (1) since it's not active. When
NextFrameConfig is called in (3) it will say that future frames may
reference T0 on both S0 and S1, but it's then dropped.
On step (4), the SVC controller essentially thinks it's encoding a new
picture and will happily reference the T0 on what it thinks is the first
delta frame. However, this is actually still the key frame and since
there was no S1T0 frame produced it will reference an invalid buffer.
To fix this, only say it's possible to reference a T0 frame after it has
been successfully encoded.
Bug: webrtc:11999, webrtc:13142, chromium:1178444
Change-Id: Iab3d2042ce0b3fa7d952b2831d1a36b1a6613a86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231695
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34982}
Unlike libvpx, the VideoBitrateAllocation expects that the bitrate
allocation is separate for each temporal layer. In this instance, if the
bitrates are not separated it will fool the SVC controller into thinking
that all temporal layers are always active.
Bug: webrtc:11999
Change-Id: Ibc33ac00b8b7716c011b94e1ec9c640cedb5274e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231693
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34980}
Call SetMaxBitrate when encoder is configured instead of in OnMaybeEncodeFrame (which is called after the initial frame dropping ->
max bitrate is not set for dropped frames).
Added support for single active stream configuration.
Bug: none
Change-Id: I33ff96e7feed70b9ea3c9b3da89f117859108347
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231681
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34973}
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}
Requesting nacks in more cases allows the delay adaptation to better
predict if it's worth it to increase the jitter buffer delay to wait for
the nacked packets to arrive.
Bug: webrtc:10178
Change-Id: I46adb76c013dbb8df0b99eb3f7a398f8f21c2bf6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231648
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34970}
This cover scenario where target bitrate is changed in a middle of
of group of frame after spatial upswitch.
This change should avoid wasting encoder resources to produce those
frames, reduce number of errors
"Encoder produced a frame for layer that wasn't requested"
Bug: webrtc:11999
Change-Id: I06045259b1cee2c21bfdabbafff3892b57c82a84
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230543
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34969}
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}
So that applications don't need to construct it from the exposed
network_thread.
The EmulatedNetworkManagerInterface::network_thread() accessor is currently
used as a way to get to emulation's SocketServer, and should be deleted
when applications of the emulation framework have migrated away from
that usage.
Bug: webrtc:13145
Change-Id: I3efa55d117cad8ac601c48a9d2d2aa62a121f9c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231649
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34964}
When SetCodecPreferences was used, the media session was adding codecs
from a list that didn't have corrected payload type mappings. As a
result, it's possible to generate offers or answers that use the same
payload type for audio and video codecs, which is a clear violation.
Bug: webrtc:12169
Change-Id: Ib7be73b4b3b4c57b8d2f374dba8b039c7a3df5a8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231620
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34961}
The experiment WebRTC-PreStreamDecoders (aka Lazy decoder creation) has
investigated the benefit of only creating a subset of all decoders
during negotiation and the remaining decoders on demand.
This CL changes the default value to only create one decoder during
negotiation. This frees up hardware resources and reduces the SDP
negotiation time.
Bug: chromium:1202042
Change-Id: I6e2206839162aa857fcc948ccd53d0ff91cbdeaf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231643
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34959}
Following Congestion avoidance and control by V. Jacobson at
https://dl.acm.org/doi/10.1145/52324.52356, use integer math instead
of floating point. Not that it matters, but it results in some code size
savings, and is more efficient. Due to not using floating point math,
some golden values in test cases were rounded a bit differently.
Bug: webrtc:12614
Change-Id: I0b7d54b8fd9ce7156e6b2582437ef5720f8838ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231229
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34956}
This is done by adding a reorder optimizer that estimates the probability of receiving reordered packets.
The optimal delay is decided by balancing the cost of increasing the delay against the probability of missing a reordered packet, resulting in a loss. This balance is decided using the `ms_per_loss_percent` parameter.
The usage and parameters can be controlled via field trial.
Bug: webrtc:10178
Change-Id: Ic484df0412af35610e74b3a6070f2bac7a926a63
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231541
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34954}
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}
The HandleXr method has output arguments that are not set when an RTCP
report cannot be parsed. We should give these a sensible default value
to avoid accessing uninitialized memory
Bug: chromium:1247182
Change-Id: I6c54260aef3834643c41b96c0709489522d82533
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231237
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34943}
