The implementation covers the latest specification, but does not
support mixed-codec simulcast at the moment.
Changing codec for audio and video is supported.
Bug: webrtc:15064
Change-Id: I09082f39e2a7d54dd4a663a8a57bf9df5a851690
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311663
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40616}
In the past, only encodings.size() == 1 was considered singlecast. But
it's possible to have singlecast via {active,inactive,inactive} too so
this condition should be updated.
This CL ignores x-goog-max-bitrate if maxBitrate was specified on *any*
encoding. This fixes the case of {active,inactive,inactive} resolving
the singlecast inconsistency, but it also takes things one step further
and ignores x-goog-max-bitrate in simulcast cases as well (if any
active encoding has a maxBitrate), as it is not clear why simulcast
should behave differently from singlecast with regards to this flag.
Bug: webrtc:15390
Change-Id: If89a488249239a6bd10fdd56c599ccd2e6ec26fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313540
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40494}
EncoderStreamFactory has two code paths for creating a stream: the
"simulcast path" and the "default path". Only the former cares about
encoding paramter's maxBitrate. The latter assumes that
`encoder_config.max_bitrate_bps` already encompasses the maxBitrate of
the first encoding, but this is not always the case.
As of M113, when scalability mode is specified, {active,inactive} does
not count as simulcast stream but as a default stream represented by
encoding[0].
The problem is that `encoder_config.max_bitrate_bps` only includes
`encodings[0].max_bitrate_bps` when `encodings.size() == 1` which isn't
the case here.
This CL fixes the problem by making the "create default stream" code
path look at the first encoding's maxBitrate and remove existing
assumptions that `encoder_config.max_bitrate_bps` encompasses
`encodings[0].max_bitrate_bps`. This is a step in the right direction
since we're trying to remove all special cases and have encodings map
1:1 with SSRCs, so the "max bps of entire stream" should indeed be a
separate limit than the per-encoding limits and it was confusing that
sometimes it included and sometimes it excluded encoding[0]'s limit.
This issue did not happen in {inactive,active} since that code path
counts as "simulcast stream", so "default stream" is only ever
applicable for index 0.
TESTED=Simulcast Playground, see https://crbug.com/1455962.
Bug: chromium:1455962
Change-Id: I7c44925b780623b5979751e8959e972293648a3d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313282
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40482}
ReconfigureEncoder() is supposed to recreate the send stream when
switching between legacy and standard API paths to ensure that the
upper and lower layers agree on the number of streams that exist
(legacy = 3 encodings but 1 stream, standard = same as encodings).
This successfully happened when going from standard to legacy but due
to a bug in the condition this did not happen when going from legacy to
standard because `scalability_mode_used` is always false here (even
though the standard path does use a scalability mode).
As a consequence, SetRtpParameters()'s call to UpdateSendState()
resulted in a DCHECK-crash. In release builds we still avoid IOOB
because active_modules.size() < rtp_streams.size() but to avoid mistakes
like this happening again in the future, the DCHECK is promoted to a
CHECK.
The fix is to remove the scalability mode condition which didn't make
sense anyway - changing scalability mode does not require recreation but
recreation is necessary when number of streams change, whether or not
scalability mode changed.
TESTED = Using Simulcast Playground and switching back and forth
between standard and legacy and changing scalability modes and
confirming from stats, see https://crbug.com/1467455.
Bug: chromium:1467455
Change-Id: Ide29742972ba83f2e0a11f135ab9b39c39d4eb49
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/313280
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40477}
since this has been shipping receive-only enabled by default since M92.
Sending remains behind a field trial.
BUG=webrtc:8151
Change-Id: Ia44f8b9cf89ee4878074d1469413d847621ce5ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310040
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40377}
to ensure consistency for both FID and FEC-FR ssrc-groups.
BUG=chromium:1454860
Change-Id: I61277e73e0a28f5773260ec62c268bdc8c2cd738
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309760
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40347}
Media*Channel objects used to subclass webrtc::Transport.
This was not an optimal design. This CL makes the transport
a member variable of MediaChannelUtil.
Bug: None
Change-Id: I85d33cc1b32b931e563b7bb2d277f1c512600831
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309800
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40328}
specified in https://github.com/w3c/webrtc-stats/pull/762
and take FlexFEC into account for receive statistics.
BUG=webrtc:15250
Change-Id: Id85775ab1f29487d5b8bf478da6e22071005901a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294881
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40325}
This groups functions for WebRtcVideoSendChannel and
WebRtcVideoReceiveChannel together, rather than interspersing them.
Bug: webrtc:13931
Change-Id: Iecb5bac18e1d370331e9eb546c6b2fde4d92963f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309460
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40312}
Added as stopped by default as it should be requested by the application,
but it should be listed as available.
Bug: webrtc:14631
Change-Id: I301cfd29c79083c97b4a43b8fdafee2dbe4887a5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308824
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40300}
In M113 we made it possible to opt-in to spec-compliant VP9 using
scalabilityMode and scaleResolutionDownBy. Since this would change
behavior in some edge cases a kill-switch flag was also added.
It turns out it was not needed (current Stable: M114) so we can remove
the flag.
Bug: webrtc:14884
Change-Id: Ie3006164c4d6e90acad1d1f4df2fe2b6e3cb2c35
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308683
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40277}
Pushing it to the list of extensions to negotiate could result
in enabling it in production.
BUG=None
Change-Id: I98599e9fbac7e2b81b3f2ad0c7759bb052d9d9d1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306101
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40250}
The preferred method to create codecs is to use the function
cricket::CreateAudioCodec or cricketCreateVideoCodec.
Empty codec objects are deprecated and should be replaced
with alternatives such as methods returning an
absl::optional object instead.
Bug: webrtc:15214
Change-Id: I7fe40f64673cd407830dbbb0e541b85a3aee93aa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307521
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40226}
Later CLs will switch to these functions, and eventually the
CreateMediaChannel will be deprecated and removed.
Bug: webrtc:13931
Change-Id: I4c5ab89659a47a501728cac217bb1a877fa50047
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307800
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40221}
Part 1 of the migration towards merging the types.
Any method that could belong to the Codec type was moved, the others
are deprecated.
Alternatives to the AudioCodec and VideoCodec constructors are introduced
to allow creating objects of an indefinite type without having to
reference the old classes.
Bug: webrtc:15214
Change-Id: I20e1aa32962821cad98e9a92c2ec86f8f75e5dd8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307220
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40213}
This completes the split-channel work for the Video side.
Note: For ease of review, the implementations in the .cc
file have not been sorted between sender and receiver. This
can be done in a later purely-editorial CL.
Bug: webrtc:13931
Change-Id: I36cf015d5facb1eed368070cb204a8763ac19a9c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307180
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40207}
This allows us to decouple implementation classes from the
MediaChannel class.
Bug: webrtc:13931
Change-Id: I22f166cac17c344f943a0382048e8086a193affa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307000
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40179}
The intent is that this object can be used instead of VideoMediaChannel,
clearing the way for decomposing VideoMediaChannel into send and
receive classes.
This CL uses it for the "both" role of WebRtcVideoEngine::CreateMediaChannel; a later CL will use it for all roles on all engines.
Bug: webrtc:13931
Change-Id: Ibd0ca2c3c45b5e3bfcced8f7e30a1edd63cf7654
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306720
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40173}
Prior to this CL, the video `jitterBufferDelay` stat was the accumulated current delay, which is a smoothened version of the target delay. This is not correct according to the spec [1]. Rather, the stat should be the accumulated time spent in the jitter buffer, for all emitted frames. This CL fixes this spec compliance problem.
Expect changes to test metrics and product monitoring as this CL rolls out.
[1]: https://www.w3.org/TR/webrtc-stats/#dom-rtcinboundrtpstreamstats-jitterbufferdelay
Tested:
1. Go to https://jsfiddle.net/jib1/0L6duga2/show
2. Apply 2.0 seconds of video delay.
3. Notice that "Video jitter buffer delay" is slightly less than 1990ms. (2000ms playoutdelayhint - 10ms render delay - Xms decode delay).
Bug: webrtc:15085
Change-Id: I42805faafd7dd3bcdcf3ad08e751e08d6de38906
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304521
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40138}
This makes the handling somewhat more uniform, and is the same
for both video and audio channels.
Bug: webrtc:13931
Change-Id: I26605c56e069e8a34e03708d45eb27a6b7492130
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306100
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40107}
Also fix one instance where access was done wrongly.
This makes certain that the split between MediaChannel types is respected
for this variable (prior to splitting the actual C++ types).
Bug: webrtc:13931
Change-Id: I8cf48ff5eddef35fda75533bb9c5075083c4ab16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305220
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40065}
by not starting the receive stream whenever it is creating.
Instead, this is controlled by the direction of the media content.
BUG=webrtc:11013
Change-Id: Iaaa0ac0aa9f90a4be776a1348f53a0f9c2b84d99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304661
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40064}
Before the channel split, the RTP modes were set by reading the
configuration of the send codec. After the split, this is done
via the SetReceiverFeedbackParams function.
This CL adds caching those parameters so that they are applied
to receive streams created after the SetReceiverFeedbackParams call.
Bug: webrtc:13931
Change-Id: I92eb651e5dd1ec68aca7f6a162e3521eb835a11d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305021
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40056}
The field trial has been enabled-by-default for several years, I
suspect it was needed during its development but there doesn't seem to
be any reason to maintain it going forward.
Its very existence blocks our long term objective to have our APIs
behave according to the W3C standards and any apps still depending on
it, if there are any, should make sure to use the APIs correctly
instead. I assume they already do any any references to this is us
forgetting to clean things up.
Bug: webrtc:15161
Change-Id: I4a6a44a15219d2e045f3d8d857b5197a064f049c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304660
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40025}
This CL removes a PostTask in response to packet receipt reception.
This is made possible due to PacketRouter lock removal in
https://webrtc-review.googlesource.com/c/src/+/300964.
Depending on how transport code is organized, this may lead to
possibility of packet receipts arriving in
RtpTransportControllerSend which may re-enter the PacingController's
ProcessPackets method, leading to out-of-order packet sends. Fix
this by detecting re-entry and avoiding a second ProcessPackets call
in the TaskQueuePacedSender.
Bug: chromium:1373439
Change-Id: I24928f2d28a240d0860fe7e4a114cedf1f13d2bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304580
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40017}
This CL introduces a new feature enabling video packet send batches.
The feature is enabled via
PeerConnectionInterface
::RTCConfiguration
::MediaConfig
::enable_send_packet_batching.
PacketOptions have been augmented with attribute "batchable" (set for
all video packets) and attribute "last_packet_in_batch" which gives
injected AsyncPacketSockets a chance to understand when a batch begins
and ends.
When the feature is on, packets are collected in RtpSenderEgress. On
reception of OnBatchComplete from PacingController, RtpSenderEgress
sends the collected batch, setting "last_packet_in_batch" to true
in the last packet.
Bug: chromium:1439830
Change-Id: I1846b9d4a8a0efd227d617691213a2e048bdc8a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303720
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40012}
This reduces dependency on the struct RTCPReportBlock and would allow to
delete it in favor of class ReportBlockData
Bug: None
Change-Id: Ia46a2516e26453724eed2e499f475f65df6cd3fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304163
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39990}
* retransmittedBytesReceived
* retransmittedPacketsReceived
added to the specification in
https://github.com/w3c/webrtc-stats/pull/735
BUG=webrtc:15096
Change-Id: I6770e5d8d09ac1c2693c918fd943b0ab257ec7ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295260
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39959}
This CL is partly a test to see if there's an impact on binary size:
- Not a big difference for binaries (decrease): -776b to -4Kb
- For libraries (libwebrtc.a) it actually increases the size: +40Kb
Secondarily this CL is basically to introduce this pattern to the
code base. In terms of LOC, this makes things slightly more compact.
From:
class Foo {
public:
Foo() {
checker_.Detach();
}
private:
SequenceChecker checker_;
};
To:
class Foo {
public:
Foo() = default;
private:
SequenceChecker checker_{SequenceChecker::kDetached};
};
Bug: none
Change-Id: I59fc34ccea10847e13455a349851ce9a0af458e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299020
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39664}
This makes "WebRTC-AllowDisablingLegacyScalability" enabled-by-default,
meaning any app can opt-in to spec-compliant simulcast when
scalabilityMode is specified.
The opt-in criteria is also made more restricitve: you now have to
specify both scalabilityMode and scaleResolutionDownBy to get simulcast,
otherwise you continue to get legacy "single stream" path.
The reason for this is not to cause any surprises in use cases like
[{scalabilityMode:"L1T1", active:true}, {active:false}, {active:false}]
In cases like this where scaleResolutionDownBy is not specified, it
defaults to 4:2:1 if simulcast is used but the legacy path caps it to
one stream, meaning full resolution. By restricing simulcast only to
cases that set scaleResolutionDownBy, we remove the risk of an app
getting a different resolution than expected due to opt-in.
Bug: webrtc:14884, webrtc:15005
Change-Id: I5efb87af60afaeb1e3ff76698d887aaa1f9d63a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298922
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39660}
Attempting to ship "WebRTC-AllowDisablingLegacyScalability" revealed a
DCHECK that happens when negotiating 3 VP9 streams prior to the
setParameters() call:
1. By default, `scalability_mode` is missing, so those 3 streams
defaulted to legacy SVC, meaning only a single stream is used.
2. Then, setParameters() was called to make
`encodings[0].scalability_mode = "L2T2_KEY"` and
`encodings[1-2].active = false`. The inactive streams were just
dummies and never expected to exist.
Without simulcast support this is OK, because both 1) and 2) are
interpreted to have a single stream. But with simulcast support, 1) is
interpreted as single stream and 2) as three streams (1 active, 2
inactive). This should be roughly the same setup, but our code treats
them differently.
The DCHECK crash was a mismatch in number of streams in one of the
layers.
The fix is to re-create the streams when the number of streams change
for this reason. The new test revealed other issues and fixes too:
- Support for multiple spatial layers (e.g. "L2T2_KEY") when multiple
encodings exist but only one encoding is active.
- Allow inactive layers not to have a scalability mode set.
A laundry list (https://crbug.com/webrtc/15028) has been created to
update known places doing "if streams == 1" that need to do "if
active streams == 1" instead.
Credit:
The RecreateWebRtcStream() fix is based on eshr@'s POC from
https://webrtc-review.googlesource.com/c/src/+/298565.
Bug: webrtc:15016
Change-Id: I909a3f83a4ef53562894549ade0a870b208cec7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298443
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/main@{#39651}
This reverts commit 75990b9a8f98ea2d597a31472fb778ec4d55f698.
Reason for revert: Breaks downstream, a use case of having three VP9
encodings, scalability mode only specified on the first layer
(L2T2_KEY) and the other two layers not having a scalability mode but
also being active=false appears to trigger a DCHECK in
call/rtp_video_sender.cc:501. More investigation needed
Original change's description:
> Ship ability to opt-in to VP9/AV1 simulcast.
>
> With this unflagging, an app can opt-in to simulcast when using multiple
> encodings by specifying RTCRtpEncodingParameters.scalabilityMode. This
> ensures backwards-compat with apps relying on 3 encodings to mean SVC
> who traditionally have not specified scalabilityMode.
>
> It fixes the spec/API bug of asking for simulcast and not getting
> simulcast. The field trial exists only as a kill-switch with a TODO to
> remove it.
>
> This ships initial support, however note that the VP9/AV1 simulcast uses
> SimulcastRateAllocator (just like VP8/H264 simulcast). This rate
> allocator uses more kbps than SvcRateAllocator. This should be revisited
> to avoid significant higher bitrates, for example when comparing VP9
> simulcast to VP9 SVC.
>
> Shipping the ability for apps to opt-in makes it easier to exercise
> these new code paths and allows initial feedback from developers, but
> due to the high bitrate (= same bitrate as VP8/H264 simulcast today)
> many apps may find that VP9 SVC is still more beneficial for BW reasons.
>
> Bug: webrtc:14884, webrtc:15005
> Change-Id: I748aae1adb47acc8a6b79b5852cff6aa47a46f5d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298046
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Evan Shrubsole <eshr@google.com>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39601}
Bug: webrtc:14884, webrtc:15005
Change-Id: Ic8f77e6a2971f493d6cd8c23faecd435058a8847
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298440
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39605}
With this unflagging, an app can opt-in to simulcast when using multiple
encodings by specifying RTCRtpEncodingParameters.scalabilityMode. This
ensures backwards-compat with apps relying on 3 encodings to mean SVC
who traditionally have not specified scalabilityMode.
It fixes the spec/API bug of asking for simulcast and not getting
simulcast. The field trial exists only as a kill-switch with a TODO to
remove it.
This ships initial support, however note that the VP9/AV1 simulcast uses
SimulcastRateAllocator (just like VP8/H264 simulcast). This rate
allocator uses more kbps than SvcRateAllocator. This should be revisited
to avoid significant higher bitrates, for example when comparing VP9
simulcast to VP9 SVC.
Shipping the ability for apps to opt-in makes it easier to exercise
these new code paths and allows initial feedback from developers, but
due to the high bitrate (= same bitrate as VP8/H264 simulcast today)
many apps may find that VP9 SVC is still more beneficial for BW reasons.
Bug: webrtc:14884, webrtc:15005
Change-Id: I748aae1adb47acc8a6b79b5852cff6aa47a46f5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298046
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39601}
The goal of the VP9 simulcast project is that when `scalability_mode`
is set, multiple encodings are always interpreted as simulcast, even
if VP9 or AV1 is used. This CL makes this so, but only if the flag
"WebRTC-AllowDisablingLegacyScalability" is "/Enabled/". This allows us
to make "SendingThreeEncodings_VP9_Simulcast" EXPECT VP9 simulcast.
When we are ready to ship we will remove the need to use the field
trial, but before we ship this we'll want to revisit if
SvcRateAllocator can be updated to support simulcast. (Today if we use
SvcRateAllocator when VP9 simulcast is used, all encodings except the
first one get bitrate=0, causing the test to fail because media is not
flowing on all layers.) For now, a TODO is added.
Bug: webrtc:14884
Change-Id: Ie20ae748b0c0405162f3a1b015ab94956ef83dae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297340
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39552}
This reverts commit 18c869bc36b342cd4a79947067e52a93a04a7808.
Reason for revert: Added a field trial that allows landing the code without affecting performance in prod.
This CL also incorporates subsequent CLs that also had to be reverted.
Original change's description:
> Revert "Use two MediaChannels for 2 directions."
>
> This reverts commit 8981a6fac3d665beac4a58b9453e6c39988a024f.
>
> Reason for revert: Quality regression detected.
>
> Original change's description:
> > Use two MediaChannels for 2 directions.
> >
> > This CL separates the two directions of MediaChannel into two separate objects that do not couple with each other.
> >
> > The notable API change is that receiver local SSRC now has to be set explicitly - before, it was done implicitly when the send-side MediaChannel had a stream added to it.
> >
> > Bug: webrtc:13931
> > Change-Id: I83c2e3c8e79f89872d5adda1bc2899f7049748b3
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288400
> > Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#39340}
>
> No-Try: true
> Bug: webrtc:13931
> Change-Id: I791997ad9eff75c3ac9cd2e4bbacf5bc6c3a3a79
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295663
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39445}
Bug: webrtc:13931
Change-Id: I1318910a685188e2b846c9040e1efc04c2c894ac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/296080
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39494}
Under the combined network/worker thread project, tasks
are unnecessarily posted to the same thread. Avoid this
by posting only if invoked on a diffferent sequence.
TESTED=presubmit + local Meet calls.
Bug: webrtc:137439
Change-Id: Ic5dd99e5fbb843ad4c54d4466138135ae81596cf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295867
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39471}
This reverts commit a087f6f1c842f1d70ad207b44c48321ab60d2d95.
Reason for revert: Needed to roll back other CL
Original change's description:
> Add plumbing for video NACK to be coupled between channels.
>
> Bug: webrtc:13931, webrtc:14920
> Change-Id: I451869e295e099a1d08c0c80e481decd53149f1b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294382
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39373}
Bug: webrtc:13931, webrtc:14920
Change-Id: I19e176e75630313da470542e7ff1e89b6d717fc9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295664
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39432}
Currently, send stats update `last_stats_log_ms_` causing receive stats
to never be logged.
This behavior was introduced in https://webrtc-review.googlesource.com/c/src/+/288750
Bug: b/270519075
Change-Id: Ie781082cfb212c1c903cbada5e393d2e7aa6150f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294743
Commit-Queue: Linus Nilsson <lnilsson@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39381}
This allows MediaChannel to know whether it's being used
for sending, receiving, or both. This is a preparatory CL
for landing the split of MediaChannel usage into sending and
receiving objects.
Bug: webrtc:13931
Change-Id: If518c8b53d5256771200a42e1b5f2b3321d26d8c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292860
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39283}
This is used when an unsignaled stream with a known payload type is received and later a RTX packet is received.
Bug: webrtc:14817
Change-Id: I29f43281cec17553e1ec2483e21b8847714d2931
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291328
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39243}
These configurations are no longer used by call. Header extensions are identified once when demuxing packets in WebrtcVideoEngine::OnPacketReceived and WebrtcVoiceEngine::OnPacketReceived.
Change-Id: I49de9005f0aa9ab32f2c5d3abcdd8bd12343022d
Bug: webrtc:7135
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291480
Owners-Override: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39236}
This ensure transport feedback is sent for RTX packets that are received before media payload packets.
Bug: webrtc:14795, webrtc:14817
Change-Id: I6a2579b87c8863e003decb2b2559ef51a852cadb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291119
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39174}
