webrtc_m130/pc/remote_audio_source.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

184 lines
5.9 KiB
C++
Raw Permalink Normal View History

/*
* Copyright 2014 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/remote_audio_source.h"
#include <stddef.h>
Use std::make_unique instead of absl::make_unique. WebRTC is now using C++14 so there is no need to use the Abseil version of std::make_unique. This CL has been created with the following steps: git grep -l absl::make_unique | sort | uniq > /tmp/make_unique.txt git grep -l absl::WrapUnique | sort | uniq > /tmp/wrap_unique.txt git grep -l "#include <memory>" | sort | uniq > /tmp/memory.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/make_unique.txt /tmp/wrap_unique.txt | sort | \ uniq > /tmp/only_make_unique.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/only_make_unique.txt /tmp/memory.txt | \ xargs grep -l "absl/memory" > /tmp/add-memory.txt git grep -l "\babsl::make_unique\b" | \ xargs sed -i "s/\babsl::make_unique\b/std::make_unique/g" git checkout PRESUBMIT.py abseil-in-webrtc.md cat /tmp/add-memory.txt | \ xargs sed -i \ 's/#include "absl\/memory\/memory.h"/#include <memory>/g' git cl format # Manual fix order of the new inserted #include <memory> cat /tmp/only_make_unique | xargs grep -l "#include <memory>" | \ xargs sed -i '/#include "absl\/memory\/memory.h"/d' git ls-files | grep BUILD.gn | \ xargs sed -i '/\/\/third_party\/abseil-cpp\/absl\/memory/d' python tools_webrtc/gn_check_autofix.py \ -m tryserver.webrtc -b linux_rel # Repead the gn_check_autofix step for other platforms git ls-files | grep BUILD.gn | \ xargs sed -i 's/absl\/memory:memory/absl\/memory/g' git cl format Bug: webrtc:10945 Change-Id: I3fe28ea80f4dd3ba3cf28effd151d5e1f19aff89 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153221 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29209}
2019-09-17 17:06:18 +02:00
#include <memory>
#include <string>
#include <utility>
#include "absl/algorithm/container.h"
#include "api/scoped_refptr.h"
#include "api/sequence_checker.h"
#include "api/task_queue/task_queue_base.h"
#include "rtc_base/checks.h"
#include "rtc_base/logging.h"
#include "rtc_base/strings/string_format.h"
#include "rtc_base/trace_event.h"
namespace webrtc {
// This proxy is passed to the underlying media engine to receive audio data as
// they come in. The data will then be passed back up to the RemoteAudioSource
// which will fan it out to all the sinks that have been added to it.
class RemoteAudioSource::AudioDataProxy : public AudioSinkInterface {
public:
explicit AudioDataProxy(RemoteAudioSource* source) : source_(source) {
RTC_DCHECK(source);
}
AudioDataProxy() = delete;
AudioDataProxy(const AudioDataProxy&) = delete;
AudioDataProxy& operator=(const AudioDataProxy&) = delete;
~AudioDataProxy() override { source_->OnAudioChannelGone(); }
// AudioSinkInterface implementation.
void OnData(const AudioSinkInterface::Data& audio) override {
source_->OnData(audio);
}
private:
const rtc::scoped_refptr<RemoteAudioSource> source_;
};
[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
RemoteAudioSource::RemoteAudioSource(
TaskQueueBase* worker_thread,
[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
OnAudioChannelGoneAction on_audio_channel_gone_action)
: main_thread_(TaskQueueBase::Current()),
worker_thread_(worker_thread),
[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
on_audio_channel_gone_action_(on_audio_channel_gone_action),
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
state_(MediaSourceInterface::kInitializing) {
RTC_DCHECK(main_thread_);
RTC_DCHECK(worker_thread_);
}
RemoteAudioSource::~RemoteAudioSource() {
RTC_DCHECK(audio_observers_.empty());
if (!sinks_.empty()) {
RTC_LOG(LS_WARNING)
<< "RemoteAudioSource destroyed while sinks_ is non-empty.";
}
}
void RemoteAudioSource::Start(
cricket::VoiceMediaReceiveChannelInterface* media_channel,
std::optional<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(worker_thread_);
// Register for callbacks immediately before AddSink so that we always get
// notified when a channel goes out of scope (signaled when "AudioDataProxy"
// is destroyed).
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);
ssrc ? media_channel->SetRawAudioSink(*ssrc,
std::make_unique<AudioDataProxy>(this))
: media_channel->SetDefaultRawAudioSink(
std::make_unique<AudioDataProxy>(this));
}
void RemoteAudioSource::Stop(
cricket::VoiceMediaReceiveChannelInterface* media_channel,
std::optional<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(worker_thread_);
RTC_DCHECK(media_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
ssrc ? media_channel->SetRawAudioSink(*ssrc, nullptr)
: media_channel->SetDefaultRawAudioSink(nullptr);
}
[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
void RemoteAudioSource::SetState(SourceState new_state) {
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(main_thread_);
[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
if (state_ != new_state) {
state_ = new_state;
FireOnChanged();
}
}
MediaSourceInterface::SourceState RemoteAudioSource::state() 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(main_thread_);
return state_;
}
bool RemoteAudioSource::remote() 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(main_thread_);
return true;
}
void RemoteAudioSource::SetVolume(double volume) {
RTC_DCHECK_GE(volume, 0);
RTC_DCHECK_LE(volume, 10);
RTC_LOG(LS_INFO) << StringFormat("RAS::%s({volume=%.2f})", __func__, volume);
for (auto* observer : audio_observers_) {
observer->OnSetVolume(volume);
}
}
void RemoteAudioSource::RegisterAudioObserver(AudioObserver* observer) {
RTC_DCHECK(observer != NULL);
RTC_DCHECK(!absl::c_linear_search(audio_observers_, observer));
audio_observers_.push_back(observer);
}
void RemoteAudioSource::UnregisterAudioObserver(AudioObserver* observer) {
RTC_DCHECK(observer != NULL);
audio_observers_.remove(observer);
}
void RemoteAudioSource::AddSink(AudioTrackSinkInterface* sink) {
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(main_thread_);
RTC_DCHECK(sink);
MutexLock lock(&sink_lock_);
RTC_DCHECK(!absl::c_linear_search(sinks_, sink));
sinks_.push_back(sink);
}
void RemoteAudioSource::RemoveSink(AudioTrackSinkInterface* sink) {
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(main_thread_);
RTC_DCHECK(sink);
MutexLock lock(&sink_lock_);
sinks_.remove(sink);
}
void RemoteAudioSource::OnData(const AudioSinkInterface::Data& audio) {
// Called on the externally-owned audio callback thread, via/from webrtc.
TRACE_EVENT0("webrtc", "RemoteAudioSource::OnData");
MutexLock lock(&sink_lock_);
for (auto* sink : sinks_) {
// When peerconnection acts as an audio source, it should not provide
// absolute capture timestamp.
sink->OnData(audio.data, 16, audio.sample_rate, audio.channels,
audio.samples_per_channel,
/*absolute_capture_timestamp_ms=*/std::nullopt);
}
}
void RemoteAudioSource::OnAudioChannelGone() {
[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
if (on_audio_channel_gone_action_ != OnAudioChannelGoneAction::kEnd) {
return;
}
// Called when the audio channel is deleted. It may be the worker thread or
// may be a different task queue.
// This object needs to live long enough for the cleanup logic in the posted
// task to run, so take a reference to it. Sometimes the task may not be
// processed (because the task queue was destroyed shortly after this call),
// but that is fine because the task queue destructor will take care of
// destroying task which will release the reference on RemoteAudioSource.
rtc::scoped_refptr<RemoteAudioSource> thiz(this);
main_thread_->PostTask([thiz = std::move(thiz)] {
thiz->sinks_.clear();
thiz->SetState(MediaSourceInterface::kEnded);
});
}
} // namespace webrtc