This is the first step in implementing custom codecs in SDP.
Bug: none
Change-Id: I7789478208a769eaefd58b410ae6f488c604594d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/348662
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#42171}
This test drives the new tools_webrtc/remove_extra_namespace.py tool.
Bug: None
Change-Id: I9b590aa1213e4cace2d64d555f4dafd893f03606
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327021
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41141}
Unsignaled SSRCs are only applicable for the receiver case (not sender).
This CL updates the receievr's GetParameters() and GetSources() methods
to lookup parameters/sources by the current SSRC (whether or not it was
signaled) instead of only looking at the signaled SSRC.
To clarify that the `ssrc_` variable inside the [Audio/Video]RtpReceiver
is the signaled ssrc (and not set if the current ssrc is unsignaled),
we rename this variable to `signaled_ssrc_`.
By the looks of it, other APIs like setting volume or packetizers also
have a dependency on the assumptions that the SSRC is signaled. We will
not address that in this CL, but this CL makes that more clear.
Bug: webrtc:14811
Change-Id: I32c93d264ab441ade23a4078639744d25b791742
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290573
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39051}
This is a reland of commit 81aab48878
See diff between Patch Set 1 and latest Patch Set.
The original CL broke this WPT[1] because getStats() with the receiver
as the selector stopped working in the event of unsignalled SSRCs due
to the receiver not knowing what the SSRC was.
This fix is to query media_channel_ for the unsignalled SSRC in the
event that the receiver does not know the SSRC.
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/simulcast/setParameters-active.https.html
Original change's description:
> Remove 'trackId' dependency in stats selector algorithm.
>
> In preparation for the deletion of deprecated 'track' stats, the
> stats selector algorithm needs to be rewritten not to use 'trackId'.
>
> This is achieved by finding RTP stats by their SSRC, as obtained via
> getParameters(). This unfortunately adds a block-invoke (in the sender
> case the block-invoke happens inside GetParametersInternal and in the
> receiver case the block-invoke is explicit at the calling place), but
> it can't be helped and it's just once per getStats() call and only if
> the selector argument is used.
>
> Bug: webrtc:14175
> Change-Id: If0e14cdbdc76d141e0042e43757970893bf32119
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/289101
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38981}
Bug: webrtc:14175, webrtc:14811
Change-Id: I0d16724af4efeb93d50e36dbfcc798564daff5c0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290600
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39010}
The implementation here has a number of changes that force the callers
that called the "channel" functions into specific interfaces rather than
just letting C++ take care of it; this should go away once there stops
being a common implementation class for those interfaces.
Bug: webrtc:13931
Change-Id: Ic4e279528a341bc0a0e88d2e1e76c90bc43a1035
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/287640
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38888}
This allows callers to differentiate on whether they need the
channel for sending or receiving purposes.
Note: This CL is incomplete, in that many places cast the pointers
to the concrete subclasses "VideoMediaChannel" and "AudioMediaChannel", which are not split into sending and receiving APIs.
The long term goal is to make two MediaChannel-like class APIs, with distinct implementations, and let the RtpSender and RtpReceiver manage those objects, rather than keeping them in the RtpTransceiver.
Bug: webrtc:13931
Change-Id: I8d56defe2287bd6552b71571cc6a5ec842927fa4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/287040
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38844}
Prior to this CL, calling RtpTransceiver::SetChannel() with null
arguments would cause the receiver's track to end. This is wrong,
because the channel can be nulled for other reasons than the transceiver
being stopped/removed - such as when the transceiver is rolled back but
still in use. Also, stopping a transceiver will end the track, so we
should simply ensure to always stop the transceiver when that is needed.
This CL makes sure that the transceiver is stopped or stopping in all
appropriate places, allowing us to remove the ability to end the source
for any other reason. A side-effect of this is that:
- The track never ends prematurely, fixing https://crbug.com/1315611.
- Removed transceivers are always stopped, fixing
https://crbug.com/webrtc/14005.
This CL fixes the issue of track being ended in the ontrack event when
running https://jsfiddle.net/henbos/nxebusjm/.
- We don't have WPT test coverage for this, so I'll add that separately.
With SetSourceEnded() removed, some stopping/stop in response to
rejecting locally SDP munged content had to be added in order not to
regress the existing test coverage for this:
*PeerConnectionInterfaceTest.RejectMediaContent/1
Bug: chromium:1315611, webrtc:14005.
Change-Id: I21f30a1259e51324066dc84f72a72485b9e0fadc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260180
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36669}
This makes SetChannel() consistently make 2 invokes instead of a
multiple of senders+receivers (previous minimum was 4 but could be
larger).
* Stop() doesn't hop to the worker thread.
* SetMediaChannel(), an already-required step on the worker thread for
senders and *sometimes* for receivers[1], is now consistently required
for both. This simplifies transceiver teardown and enables the next
bullet.
* Transceiver stops all senders and receivers in one go rather than
ping ponging between threads.
[1] When not required, it was done implicitly inside of Stop().
See changes in `RtpTransceiver::SetChannel`
Bug: webrtc:13540
Change-Id: Ied61636c8ef09d782bf519524fff2a31e15219a8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249797
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36057}
This is a reland of 3ed36c0521
Original change's description:
> Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver."
>
> This is a reland of bb57e2d7aa
>
> 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}
This reverts commit 3ed36c0521.
Reason for revert: Breaks downstream project.
Original change's description:
> Reland "Remove `stopped_` from AudioRtpReceiver and VideoRtpReceiver."
>
> This is a reland of bb57e2d7aa
>
> 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}
TBR=ilnik@webrtc.org,tommi@webrtc.org,hta@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: Ieb7235d88c808c78ad0847403be991d4dce1ace6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:13540
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251383
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35963}
This is a reland of bb57e2d7aa
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}
This reverts commit bb57e2d7aa.
Reason for revert: Speculative revert to see if this is causing
breakage in Chromium
Bug: chromium:13665
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}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:13540
Change-Id: I67fb2c26b6931b80e3aab749443122d62a82855d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251141
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35938}
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}
This reverts commit 37ee0f5e59.
Reason for revert: Revert in order to be able to revert https://webrtc-review.googlesource.com/c/src/+/225642
Original change's description:
> Use backticks not vertical bars to denote variables in comments for /pc
>
> Bug: webrtc:12338
> Change-Id: I88cf10afa5fc810b95d2a585ab2e895dcc163b63
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226953
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Artem Titov <titovartem@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34575}
TBR=hta@webrtc.org,titovartem@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I5eddd3a14e1f664bf831e5c294fbc4de5f6a88af
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:12338
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227082
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34577}
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}
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}
The frame transformer is passed from RTPReceiverInterface through the
library to be eventually set in ChannelReceive, where the frame
transformation will occur in the follow-up CL.
Insertable Streams Web API explainer:
https://github.com/alvestrand/webrtc-media-streams/blob/master/explainer.md
Design doc for WebRTC library changes:
http://doc/1eiLkjNUkRy2FssCPLUp6eH08BZuXXoHfbbBP1ZN7EVk
Bug: webrtc:11380
Change-Id: I5af06d1431047ef50d00e304cf95e92a832b4220
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171872
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30956}
This removes the SetParameters method from AudioRtpReceiver and Video
RtpReceiver, which is currently not used and is not part of the
specifications.
Bug: webrtc:11111
Change-Id: I6f67773bfef2d4b51e9ab670bde17b5fbf5f94c3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/159307
Reviewed-by: Patrik Höglund <phoglund@google.com>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Daniela Jovanoska Petrenko <denicija@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Saurav Das <dinosaurav@chromium.org>
Cr-Commit-Position: refs/heads/master@{#29995}
Changes Rtp Receivers to use a null value of ssrc to mean a default
receive stream.
Bug: webrtc:8694
Change-Id: I835199345f7add993b9078c8b0e7988d5cdd6646
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152425
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Saurav Das <dinosaurav@chromium.org>
Cr-Commit-Position: refs/heads/master@{#29201}
