which come from the a=fmtp:<pt> lines in the SDP and were used as either
std::map<std::string, std:string>
with three aliases,
cricket::CodecParameterMap
SdpAudioFormat::Parameters
SdpVideoFormat::Parameters
Use webrtc::CodecParameterMap in all places.
BUG=None
Change-Id: If47692bde7347834c349c6539b43309d8770e67b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330420
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@{#41375}
instead of throwing an error when trying to pick a send codec.
BUG=webrtc:15145,webrtc:4957
Change-Id: I056b145c093348576e1aeaf5def50d5414f2de70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330122
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41360}
This adds neccessary checks for SDP negotiation with HEVC.
Test: Manually apply the CL on Chromium and enable HEVC HW encoder,
and add HEVC profiles in rtc video decoder/encoder factory, H265 is
negotiated in SDP with correct FMTP lines added.
Bug: webrtc:13485
Change-Id: I5557b20b646cc96c5acb578521204fe10df0dcf0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330202
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#41357}
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}
