webrtc_m130/pc/audio_rtp_receiver.cc

338 lines
11 KiB
C++
Raw Normal View History

/*
* Copyright 2019 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#include "pc/audio_rtp_receiver.h"
#include <stddef.h>
#include <string>
#include <utility>
#include <vector>
#include "api/sequence_checker.h"
#include "pc/audio_track.h"
#include "pc/media_stream_track_proxy.h"
#include "rtc_base/checks.h"
namespace webrtc {
AudioRtpReceiver::AudioRtpReceiver(
rtc::Thread* worker_thread,
std::string receiver_id,
std::vector<std::string> stream_ids,
bool is_unified_plan,
cricket::VoiceMediaChannel* voice_channel /*= nullptr*/)
: AudioRtpReceiver(worker_thread,
receiver_id,
[Unified Plan] Don't end audio tracks when SSRC changes. The RemoteAudioSource has an AudioDataProxy that acts as a sink, passing along data from AudioRecvStreams to the RemoteAudioSource. If an SSRC is changed (or other reconfiguration happens) with SDP, the recv stream and proxy get recreated. In Plan B, because remote tracks maps 1:1 with SSRCs, it made sense to end remote track/audio source in response to this. In Plan B, a new receiver, with a new track and a new proxy would be created for the new SSRC. In Unified Plan however, remote tracks correspond to m= sections. The remote track should only end on port:0 (or RTCP BYE or timeout, etc), not because the recv stream of an m= section is recreated. The code already supports changing SSRC and this is working correctly, but because ~AudioDataProxy() would end the source this would cause the MediaStreamTrack of the receiver to end (even though the media engine is still processing the remote audio stream correctly under the hood). This issue only happened on audio tracks, and because of timing of PostTasks the track would kEnd in Chromium *after* promise.then(). This CL fixes that issue by not ending the source when the proxy is destroyed. Destroying a recv stream is a temporary action in Unified Plan, unless stopped. Tests are added ensuring tracks are kLive. I have manually verified that this CL fixes the issue and that both audio and video is flowing through the entire pipeline: https://jsfiddle.net/henbos/h21xec97/122/ Bug: chromium:1121454 Change-Id: Ic21ac8ea263ccf021b96a14d3e4e3b24eb756c86 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214136 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33645}
2021-04-08 07:25:38 +02:00
CreateStreamsFromIds(std::move(stream_ids)),
is_unified_plan,
voice_channel) {}
AudioRtpReceiver::AudioRtpReceiver(
rtc::Thread* worker_thread,
const std::string& receiver_id,
[Unified Plan] Don't end audio tracks when SSRC changes. The RemoteAudioSource has an AudioDataProxy that acts as a sink, passing along data from AudioRecvStreams to the RemoteAudioSource. If an SSRC is changed (or other reconfiguration happens) with SDP, the recv stream and proxy get recreated. In Plan B, because remote tracks maps 1:1 with SSRCs, it made sense to end remote track/audio source in response to this. In Plan B, a new receiver, with a new track and a new proxy would be created for the new SSRC. In Unified Plan however, remote tracks correspond to m= sections. The remote track should only end on port:0 (or RTCP BYE or timeout, etc), not because the recv stream of an m= section is recreated. The code already supports changing SSRC and this is working correctly, but because ~AudioDataProxy() would end the source this would cause the MediaStreamTrack of the receiver to end (even though the media engine is still processing the remote audio stream correctly under the hood). This issue only happened on audio tracks, and because of timing of PostTasks the track would kEnd in Chromium *after* promise.then(). This CL fixes that issue by not ending the source when the proxy is destroyed. Destroying a recv stream is a temporary action in Unified Plan, unless stopped. Tests are added ensuring tracks are kLive. I have manually verified that this CL fixes the issue and that both audio and video is flowing through the entire pipeline: https://jsfiddle.net/henbos/h21xec97/122/ Bug: chromium:1121454 Change-Id: Ic21ac8ea263ccf021b96a14d3e4e3b24eb756c86 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214136 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33645}
2021-04-08 07:25:38 +02:00
const std::vector<rtc::scoped_refptr<MediaStreamInterface>>& streams,
bool is_unified_plan,
cricket::VoiceMediaChannel* voice_channel /*= nullptr*/)
: worker_thread_(worker_thread),
id_(receiver_id),
source_(rtc::make_ref_counted<RemoteAudioSource>(
[Unified Plan] Don't end audio tracks when SSRC changes. The RemoteAudioSource has an AudioDataProxy that acts as a sink, passing along data from AudioRecvStreams to the RemoteAudioSource. If an SSRC is changed (or other reconfiguration happens) with SDP, the recv stream and proxy get recreated. In Plan B, because remote tracks maps 1:1 with SSRCs, it made sense to end remote track/audio source in response to this. In Plan B, a new receiver, with a new track and a new proxy would be created for the new SSRC. In Unified Plan however, remote tracks correspond to m= sections. The remote track should only end on port:0 (or RTCP BYE or timeout, etc), not because the recv stream of an m= section is recreated. The code already supports changing SSRC and this is working correctly, but because ~AudioDataProxy() would end the source this would cause the MediaStreamTrack of the receiver to end (even though the media engine is still processing the remote audio stream correctly under the hood). This issue only happened on audio tracks, and because of timing of PostTasks the track would kEnd in Chromium *after* promise.then(). This CL fixes that issue by not ending the source when the proxy is destroyed. Destroying a recv stream is a temporary action in Unified Plan, unless stopped. Tests are added ensuring tracks are kLive. I have manually verified that this CL fixes the issue and that both audio and video is flowing through the entire pipeline: https://jsfiddle.net/henbos/h21xec97/122/ Bug: chromium:1121454 Change-Id: Ic21ac8ea263ccf021b96a14d3e4e3b24eb756c86 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214136 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33645}
2021-04-08 07:25:38 +02:00
worker_thread,
is_unified_plan
? RemoteAudioSource::OnAudioChannelGoneAction::kSurvive
: RemoteAudioSource::OnAudioChannelGoneAction::kEnd)),
track_(AudioTrackProxyWithInternal<AudioTrack>::Create(
rtc::Thread::Current(),
AudioTrack::Create(receiver_id, source_))),
media_channel_(voice_channel),
cached_track_enabled_(track_->internal()->enabled()),
attachment_id_(GenerateUniqueId()),
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
worker_thread_safety_(PendingTaskSafetyFlag::CreateDetachedInactive()) {
RTC_DCHECK(worker_thread_);
RTC_DCHECK(track_->GetSource()->remote());
track_->RegisterObserver(this);
track_->GetSource()->RegisterAudioObserver(this);
SetStreams(streams);
}
AudioRtpReceiver::~AudioRtpReceiver() {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
RTC_DCHECK(!media_channel_);
track_->GetSource()->UnregisterAudioObserver(this);
track_->UnregisterObserver(this);
}
void AudioRtpReceiver::OnChanged() {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
const bool enabled = track_->internal()->enabled();
if (cached_track_enabled_ == enabled)
return;
cached_track_enabled_ = enabled;
worker_thread_->PostTask(SafeTask(worker_thread_safety_, [this, enabled]() {
RTC_DCHECK_RUN_ON(worker_thread_);
Reconfigure(enabled);
}));
}
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
void AudioRtpReceiver::SetOutputVolume_w(double volume) {
RTC_DCHECK_RUN_ON(worker_thread_);
RTC_DCHECK_GE(volume, 0.0);
RTC_DCHECK_LE(volume, 10.0);
Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver." This is a reland of 3ed36c0521546881656c73984456485dcab16205 Original change's description: > Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver." > > This is a reland of bb57e2d7aa9b36843233d1394422f03d12d9c31f > > The difference from the original CL is that a check for > `state_ == kLive` inside of RemoteAudioSource::AddSink has been removed. > This caused a side effect that registering the sink while the source > was in an "initializing" state, failed. The last remaining state > however, is `kEnded` - but since there's no logic in the class around > the expected value of the states, the check inside of AddSink() > doesn't provide an additional value - it's rather a surprise for > developers if it doesn't succeed. So, now removed. > > Original change's description: > > Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver. > > > > This simplifies the logic in these classes a bit, which makes upcoming > > change easier. The `stopped_` flag in these classes was essentially > > the same thing as `media_channel_ == nullptr`, which is what's > > consistently used now for the same checks. > > > > Bug: webrtc:13540 > > Change-Id: Ib60bfad9f28d5ddee8a8d5170c3f2a7ef017a5ca > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250163 > > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#35907} > > Bug: webrtc:13540 > Change-Id: I3e5b3046fae11cb56b50c38c5f08972a6f283dd5 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251326 > Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org> > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Commit-Queue: Harald Alvestrand <hta@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#35958} Bug: webrtc:13540 Change-Id: I6d7d67fddb1ddfc69a302f0f69a9b815f2fd82f7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251386 Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35967}
2022-02-08 21:12:15 +01:00
if (!media_channel_)
return;
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
ssrc_ ? media_channel_->SetOutputVolume(*ssrc_, volume)
: media_channel_->SetDefaultOutputVolume(volume);
}
void AudioRtpReceiver::OnSetVolume(double volume) {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
RTC_DCHECK_GE(volume, 0);
RTC_DCHECK_LE(volume, 10);
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
bool track_enabled = track_->internal()->enabled();
worker_thread_->BlockingCall([&]() {
RTC_DCHECK_RUN_ON(worker_thread_);
// Update the cached_volume_ even when stopped, to allow clients to set
// the volume before starting/restarting, eg see crbug.com/1272566.
cached_volume_ = volume;
// When the track is disabled, the volume of the source, which is the
// corresponding WebRtc Voice Engine channel will be 0. So we do not
// allow setting the volume to the source when the track is disabled.
if (track_enabled)
SetOutputVolume_w(volume);
});
}
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
rtc::scoped_refptr<DtlsTransportInterface> AudioRtpReceiver::dtls_transport()
const {
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
return dtls_transport_;
}
std::vector<std::string> AudioRtpReceiver::stream_ids() const {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
std::vector<std::string> stream_ids(streams_.size());
for (size_t i = 0; i < streams_.size(); ++i)
stream_ids[i] = streams_[i]->id();
return stream_ids;
}
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
std::vector<rtc::scoped_refptr<MediaStreamInterface>>
AudioRtpReceiver::streams() const {
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
return streams_;
}
RtpParameters AudioRtpReceiver::GetParameters() const {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(worker_thread_);
if (!media_channel_)
return RtpParameters();
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
return ssrc_ ? media_channel_->GetRtpReceiveParameters(*ssrc_)
: media_channel_->GetDefaultRtpReceiveParameters();
}
void AudioRtpReceiver::SetFrameDecryptor(
rtc::scoped_refptr<FrameDecryptorInterface> frame_decryptor) {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(worker_thread_);
frame_decryptor_ = std::move(frame_decryptor);
// Special Case: Set the frame decryptor to any value on any existing channel.
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
if (media_channel_ && ssrc_) {
media_channel_->SetFrameDecryptor(*ssrc_, frame_decryptor_);
}
}
rtc::scoped_refptr<FrameDecryptorInterface>
AudioRtpReceiver::GetFrameDecryptor() const {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(worker_thread_);
return frame_decryptor_;
}
void AudioRtpReceiver::Stop() {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver." This is a reland of 3ed36c0521546881656c73984456485dcab16205 Original change's description: > Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver." > > This is a reland of bb57e2d7aa9b36843233d1394422f03d12d9c31f > > The difference from the original CL is that a check for > `state_ == kLive` inside of RemoteAudioSource::AddSink has been removed. > This caused a side effect that registering the sink while the source > was in an "initializing" state, failed. The last remaining state > however, is `kEnded` - but since there's no logic in the class around > the expected value of the states, the check inside of AddSink() > doesn't provide an additional value - it's rather a surprise for > developers if it doesn't succeed. So, now removed. > > Original change's description: > > Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver. > > > > This simplifies the logic in these classes a bit, which makes upcoming > > change easier. The `stopped_` flag in these classes was essentially > > the same thing as `media_channel_ == nullptr`, which is what's > > consistently used now for the same checks. > > > > Bug: webrtc:13540 > > Change-Id: Ib60bfad9f28d5ddee8a8d5170c3f2a7ef017a5ca > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250163 > > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#35907} > > Bug: webrtc:13540 > Change-Id: I3e5b3046fae11cb56b50c38c5f08972a6f283dd5 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251326 > Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org> > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Commit-Queue: Harald Alvestrand <hta@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#35958} Bug: webrtc:13540 Change-Id: I6d7d67fddb1ddfc69a302f0f69a9b815f2fd82f7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251386 Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35967}
2022-02-08 21:12:15 +01:00
source_->SetState(MediaSourceInterface::kEnded);
track_->internal()->set_ended();
}
void AudioRtpReceiver::RestartMediaChannel(absl::optional<uint32_t> ssrc) {
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
bool enabled = track_->internal()->enabled();
Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver." This is a reland of 3ed36c0521546881656c73984456485dcab16205 Original change's description: > Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver." > > This is a reland of bb57e2d7aa9b36843233d1394422f03d12d9c31f > > The difference from the original CL is that a check for > `state_ == kLive` inside of RemoteAudioSource::AddSink has been removed. > This caused a side effect that registering the sink while the source > was in an "initializing" state, failed. The last remaining state > however, is `kEnded` - but since there's no logic in the class around > the expected value of the states, the check inside of AddSink() > doesn't provide an additional value - it's rather a surprise for > developers if it doesn't succeed. So, now removed. > > Original change's description: > > Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver. > > > > This simplifies the logic in these classes a bit, which makes upcoming > > change easier. The `stopped_` flag in these classes was essentially > > the same thing as `media_channel_ == nullptr`, which is what's > > consistently used now for the same checks. > > > > Bug: webrtc:13540 > > Change-Id: Ib60bfad9f28d5ddee8a8d5170c3f2a7ef017a5ca > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250163 > > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#35907} > > Bug: webrtc:13540 > Change-Id: I3e5b3046fae11cb56b50c38c5f08972a6f283dd5 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251326 > Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org> > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Commit-Queue: Harald Alvestrand <hta@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#35958} Bug: webrtc:13540 Change-Id: I6d7d67fddb1ddfc69a302f0f69a9b815f2fd82f7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251386 Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35967}
2022-02-08 21:12:15 +01:00
MediaSourceInterface::SourceState state = source_->state();
worker_thread_->BlockingCall([&]() {
RTC_DCHECK_RUN_ON(worker_thread_);
RestartMediaChannel_w(std::move(ssrc), enabled, state);
});
Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver." This is a reland of 3ed36c0521546881656c73984456485dcab16205 Original change's description: > Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver." > > This is a reland of bb57e2d7aa9b36843233d1394422f03d12d9c31f > > The difference from the original CL is that a check for > `state_ == kLive` inside of RemoteAudioSource::AddSink has been removed. > This caused a side effect that registering the sink while the source > was in an "initializing" state, failed. The last remaining state > however, is `kEnded` - but since there's no logic in the class around > the expected value of the states, the check inside of AddSink() > doesn't provide an additional value - it's rather a surprise for > developers if it doesn't succeed. So, now removed. > > Original change's description: > > Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver. > > > > This simplifies the logic in these classes a bit, which makes upcoming > > change easier. The `stopped_` flag in these classes was essentially > > the same thing as `media_channel_ == nullptr`, which is what's > > consistently used now for the same checks. > > > > Bug: webrtc:13540 > > Change-Id: Ib60bfad9f28d5ddee8a8d5170c3f2a7ef017a5ca > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250163 > > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#35907} > > Bug: webrtc:13540 > Change-Id: I3e5b3046fae11cb56b50c38c5f08972a6f283dd5 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251326 > Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org> > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Commit-Queue: Harald Alvestrand <hta@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#35958} Bug: webrtc:13540 Change-Id: I6d7d67fddb1ddfc69a302f0f69a9b815f2fd82f7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251386 Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35967}
2022-02-08 21:12:15 +01:00
source_->SetState(MediaSourceInterface::kLive);
}
void AudioRtpReceiver::RestartMediaChannel_w(
absl::optional<uint32_t> ssrc,
bool track_enabled,
MediaSourceInterface::SourceState state) {
RTC_DCHECK_RUN_ON(worker_thread_);
if (!media_channel_)
return; // Can't restart.
// Make sure the safety flag is marked as `alive` for cases where the media
// channel was provided via the ctor and not an explicit call to
// SetMediaChannel.
worker_thread_safety_->SetAlive();
if (state != MediaSourceInterface::kInitializing) {
if (ssrc_ == ssrc)
return;
source_->Stop(media_channel_, ssrc_);
}
ssrc_ = std::move(ssrc);
source_->Start(media_channel_, ssrc_);
if (ssrc_) {
media_channel_->SetBaseMinimumPlayoutDelayMs(*ssrc_, delay_.GetMs());
}
Reconfigure(track_enabled);
}
void AudioRtpReceiver::SetupMediaChannel(uint32_t ssrc) {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
RestartMediaChannel(ssrc);
}
void AudioRtpReceiver::SetupUnsignaledMediaChannel() {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
RestartMediaChannel(absl::nullopt);
}
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
uint32_t AudioRtpReceiver::ssrc() const {
RTC_DCHECK_RUN_ON(worker_thread_);
return ssrc_.value_or(0);
}
void AudioRtpReceiver::set_stream_ids(std::vector<std::string> stream_ids) {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
SetStreams(CreateStreamsFromIds(std::move(stream_ids)));
}
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
void AudioRtpReceiver::set_transport(
rtc::scoped_refptr<DtlsTransportInterface> dtls_transport) {
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
dtls_transport_ = std::move(dtls_transport);
}
void AudioRtpReceiver::SetStreams(
const std::vector<rtc::scoped_refptr<MediaStreamInterface>>& streams) {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
// Remove remote track from any streams that are going away.
for (const auto& existing_stream : streams_) {
bool removed = true;
for (const auto& stream : streams) {
if (existing_stream->id() == stream->id()) {
RTC_DCHECK_EQ(existing_stream.get(), stream.get());
removed = false;
break;
}
}
if (removed) {
existing_stream->RemoveTrack(audio_track());
}
}
// Add remote track to any streams that are new.
for (const auto& stream : streams) {
bool added = true;
for (const auto& existing_stream : streams_) {
if (stream->id() == existing_stream->id()) {
RTC_DCHECK_EQ(stream.get(), existing_stream.get());
added = false;
break;
}
}
if (added) {
stream->AddTrack(audio_track());
}
}
streams_ = streams;
}
std::vector<RtpSource> AudioRtpReceiver::GetSources() const {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(worker_thread_);
if (!media_channel_ || !ssrc_) {
return {};
}
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
return media_channel_->GetSources(*ssrc_);
}
void AudioRtpReceiver::SetDepacketizerToDecoderFrameTransformer(
rtc::scoped_refptr<webrtc::FrameTransformerInterface> frame_transformer) {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(worker_thread_);
if (media_channel_) {
media_channel_->SetDepacketizerToDecoderFrameTransformer(ssrc_.value_or(0),
frame_transformer);
}
frame_transformer_ = std::move(frame_transformer);
}
void AudioRtpReceiver::Reconfigure(bool track_enabled) {
RTC_DCHECK_RUN_ON(worker_thread_);
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK(media_channel_);
SetOutputVolume_w(track_enabled ? cached_volume_ : 0);
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
if (ssrc_ && frame_decryptor_) {
// Reattach the frame decryptor if we were reconfigured.
media_channel_->SetFrameDecryptor(*ssrc_, frame_decryptor_);
}
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
if (frame_transformer_) {
media_channel_->SetDepacketizerToDecoderFrameTransformer(
ssrc_.value_or(0), frame_transformer_);
}
}
void AudioRtpReceiver::SetObserver(RtpReceiverObserverInterface* observer) {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
observer_ = observer;
// Deliver any notifications the observer may have missed by being set late.
if (received_first_packet_ && observer_) {
observer_->OnFirstPacketReceived(media_type());
}
}
void AudioRtpReceiver::SetJitterBufferMinimumDelay(
absl::optional<double> delay_seconds) {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(worker_thread_);
delay_.Set(delay_seconds);
if (media_channel_ && ssrc_)
media_channel_->SetBaseMinimumPlayoutDelayMs(*ssrc_, delay_.GetMs());
}
void AudioRtpReceiver::SetMediaChannel(cricket::MediaChannel* media_channel) {
RTC_DCHECK_RUN_ON(worker_thread_);
RTC_DCHECK(media_channel == nullptr ||
media_channel->media_type() == media_type());
if (!media_channel && media_channel_)
SetOutputVolume_w(0.0);
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
media_channel ? worker_thread_safety_->SetAlive()
: worker_thread_safety_->SetNotAlive();
media_channel_ = static_cast<cricket::VoiceMediaChannel*>(media_channel);
}
void AudioRtpReceiver::NotifyFirstPacketReceived() {
VideoRtpReceiver & AudioRtpReceiver threading fixes. For implementations where the signaling and worker threads are not the same thread, this significantly cuts down on Thread::Invoke()s that would block the signaling thread while waiting for the worker thread. For Audio and Video Rtp receivers, the following methods now do not block the signaling thread: * GetParameters * SetJitterBufferMinimumDelay * GetSources * SetFrameDecryptor / GetFrameDecryptor * SetDepacketizerToDecoderFrameTransformer Importantly this change also makes the track() accessor accessible directly from the application thread (bypassing the proxy) since for receiver objects, the track object is const. Other changes: * Remove RefCountedObject inheritance, use make_ref_counted instead. * Every member variable in the rtp receiver classes is now RTC_GUARDED * Stop() now fully clears up worker thread state, and Stop() is consistently called before destruction. This means that there's one thread hop instead of at least 4 before (sometimes more), per receiver. * OnChanged triggered volume for audio tracks is done asynchronously. * Deleted most of the JitterBufferDelay implementation. Turns out that it was largely unnecessary overhead and complexity. It seems that these two classes are copy/pasted to a large extent so further refactoring would be good in the future, as to not have to fix each issue twice. Bug: chromium:1184611 Change-Id: I1ba5c3abbd1b0571f7d12850d64004fd2d83e5e2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218605 Commit-Queue: Tommi <tommi@webrtc.org> Reviewed-by: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34022}
2021-05-17 14:50:10 +02:00
RTC_DCHECK_RUN_ON(&signaling_thread_checker_);
if (observer_) {
observer_->OnFirstPacketReceived(media_type());
}
received_first_packet_ = true;
}
} // namespace webrtc