Update most of the webrtc tests to use EnableMediaWithDefaults instead of SetMediaEngineDefaults
Bug: webrtc:15574
Change-Id: I489a09e4ea3479dc26829ee0c1235e67bcbca7c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325485
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41059}
instead of requiring to pass in call_factory and media_engine
webrtc users should set media_factory member and media dependencies into PeerConnectionFactoryDependencies
Bug: webrtc:15574
Change-Id: I2dc584fe7afa41c9f170bdc51533396155cdcb06
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325320
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41049}
kDefaultQpMax=56 was defined in multiple places. Move it to media_constants and split it into two: VPx/AV1 and H26x values. H26x value is set to 51 which is the max bitstream QP value for H264/5.
This CL is expected to be a no-op because:
1. VideoCodec::qpMax value has not changed for VP8/9 and AV1.
2. VideoCodec::qpMax is currently not used by OpenH264 wrapper (wiring it up is out-of-scope of this CL).
3. Previous default qpMax=56 exceeded the max value for H26x (=51). External HW H26x encoders likely clamped it and used 51.
Bug: webrtc:14852
Change-Id: I1d795e695dac5c78e86ed829b24281e61066f668
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324282
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40997}
In some very high-bandwidth application there have been observations of
packet loss in the socket implementation (not on the network itself) due
to large bursts of packets arriving. Allocating too big buffers can of
course lead to issue as well, so this flag is intended to find a good
tradeoff.
Bug: webrtc:15585
Change-Id: I63eccb1a9f34d852d80c286fc27bffd17818f0ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324021
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40963}
Because of our asymmetrical codec situation, it's possible to have
send only codecs that we cannot negotiate even with ourselves.
This means that we should not have a DCHECK, but just a plain error.
Bug: webrtc:15064
Change-Id: I0c170e5c7f356197bcb04bcecb8259c344423ccb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323183
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40939}
This makes it consistent with how things are done in webrtc_video_engine.cc
This will improve the JS code by not having to initialize an audio
track every time frames need to be sent over, especially from another
peer connection in case of encoded transforms.
Bug: chromium:1477192
Change-Id: I3f938ad812ff377599a3799d4c2d2cd85149189e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322702
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tony Herre <herre@google.com>
Commit-Queue: Palak Agarwal <agpalak@google.com>
Cr-Commit-Position: refs/heads/main@{#40917}
Convert most field trials used in PCLF tests.
Change-Id: I26c0c4b1164bb0870aae1a488942cde888cb459d
Bug: webrtc:10335
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322703
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40909}
To avoid name collision with Timestamp type,
To avoid confusion with capture time represented as Timestamp
Bug: webrtc:9378
Change-Id: I8438a9cf4316e5f81d98c2af9dc9454c21c78e70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320601
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40796}
The main goal of this change is to disable the quality scaler when multiple spatial layers are used.
Bug: b/295129711
Change-Id: I25e0b7440a8c2adee3e97720a1e0ee5e0a914334
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319181
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40709}
disallowing more than one ssrc-group with the same semantic
and primary ssrc.
BUG=chromium:1477075
Change-Id: I4bce0555cd49834725d9b97693d26c971bc5d5c2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318822
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40694}
similar to what is done for FID and FEC-FR but SIM can have more than
one secondary SSRC.
BUG=chromium:1477075
Change-Id: I4c9b4feaa421f53e424fc17bfc9ee2c185c68fb0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318520
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40679}
following the previous change to rename the classes derived from
cricket::RtpParameters
Also rename ChangedRecvParameters to ChangedReceiveParameters.
BUG=webrtc:13931
Change-Id: Ia51dd39905a5cbb98162c3948930e43ccaf3786d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/314500
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40677}
Remove EncodedFrame::MissingFrame, as it was always false in actual
in-use code anyway, and remove usages of the Decode missing_frames param
within WebRTC. Uses/overrides in other projects will be cleaned up
shortly, allowing that variant to be removed from the interface.
Bug: webrtc:15444
Change-Id: Id299d82e441a351deff81c0f2812707a985d23d8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/317802
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Tony Herre <herre@google.com>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#40662}
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}
This CL adds [[deprecated]] to the old signatures, and uses the new
signatures throughout.
Bug: webrtc:14870
Change-Id: Ic9a8198ac0a2f954e1b2e7d05a55dbe04342f958
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/314962
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40517}
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}
This reverts commit ebf71114a326080d523b3bc0c2160b2d848d8910.
Reason for revert: Breaks downstream project.
Original change's description:
> Clean up WebRTC-FilterAbsSendTimeExtension field trial
>
> which has been enabled by default for a while. Also document the
> expected behavior, see
> https://groups.google.com/g/discuss-webrtc/c/vfrnxWBVcdA/m/ASf7dBJOGAAJ
> for more details.
>
> BUG=webrtc:10234
>
> Change-Id: If793e2b4b6cebb07371bfdf1f94ed8d49bf2bb34
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311281
> Commit-Queue: Philipp Hancke <phancke@microsoft.com>
> Reviewed-by: Konrad Hofbauer <hofbauer@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#40417}
BUG=webrtc:10234
Change-Id: I856991260ff40a24f03f6054a5c2a9e6f37f47da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311803
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40438}
which has been enabled by default for a while. Also document the
expected behavior, see
https://groups.google.com/g/discuss-webrtc/c/vfrnxWBVcdA/m/ASf7dBJOGAAJ
for more details.
BUG=webrtc:10234
Change-Id: If793e2b4b6cebb07371bfdf1f94ed8d49bf2bb34
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311281
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Konrad Hofbauer <hofbauer@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40417}
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}
into separate sections for each implemented class.
Bug: webrtc:13931
Change-Id: I600f49f3fb195761d13d304f112f36c7c62689df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308120
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40260}
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}
It is not used any more.
Bug: webrtc:13931
Change-Id: I266de41abe239907c6d65f4b182a8dc3aacaba3d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308022
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40234}
