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}
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}
in order to not regress existing use-cases while following rules
described by the specification. This change now makes the existing
regression test pass after the spec-compliant modifications.
BUG=chromium:1051821
Change-Id: Ia384adf9a172ed88b5ec6a3cc5c478764a686cb9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299002
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39726}
This reverts commit be03c0971863c9e6807fcbdb4175754e8242a652.
Causes regression in web projects that
1/ add a stopped-by-default extension in SRD
2/ call createAnswer
3/ munge the stopped-by-default extension back in SLD
4/ create a subsequent offer and expect the extension to be present
BUG=chromium:1051821
Change-Id: If77f77c2c0ac19625f502fb8a07facd151475807
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298744
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39655}
as described in https://w3c.github.io/webrtc-extensions/#modifications-to-existing-procedures-0
"For each RTP header extension "e" listed in
[[HeaderExtensionsToOffer]] where direction is not "stopped", an
"a=extmap" line, as specified in [RFC5285], section 5
This avoids including them in case they are stopped on one
transceiver but not the other. Also, this allows extensions to
be removed from a subsequent offer.
See also
https://github.com/w3c/webrtc-extensions/issues/140
BUG=chromium:1051821
Change-Id: I4d7462f939ce4cd5d8c2331bc038200fe18f70e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291703
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39242}
for video dealing with both the case where there is no common media
codec as well as only a red/ulpfec/flexfec codec in common for video
and only RED/CN in common for audio
BUG=webrtc:4957,webrtc:14069
Change-Id: I1c888b4f77199aade8122051c31b690dc2fd5925
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262642
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36920}
This cl/
1) move WebRtcKeyValueConfig from api/transport to api/ directory.
2) add a test/ScopedKeyValueConfig (compare ScopedFieldTrials).
3) removes usage of webrtc::field_trial:: from the pc/ directory.
4) removes a few unused includes of system_wrappers/field_trial.h.
Bug: webrtc:10335
Change-Id: If29c07900dbe791050b0a5ad05332bedfad035f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/253903
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36160}
Also apply IWYU to all .cc files in pc/, and correct BUILD file to match.
Note: Some files came out wrong when iwyu was applied. These are not included.
Bug: none
Change-Id: Ib5ea46b8fcc505414d0447cca7218ad3afc2e321
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/252280
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36064}
Add implementation of RTC_DCHECK_NOTREACHED equal to the RTC_NOTREACHED.
The new macros will replace the old one when old one's usage will be
removed. The idea of the renaming to provide a clear signal that this
is debug build only macros and will be stripped in the production build.
Bug: webrtc:9065
Change-Id: I4c35d8b03e74a4b3fd1ae75dba2f9c05643101db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237802
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35348}
Removes the ability to accept nonencrypted answers to encrypted offers.
Fixes some logic around bundled sessions and requirement for
transport parameters.
Bug: webrtc:11066
Change-Id: I56d8628d223614918a1e5260fdb8a117c8c02dbd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236344
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35298}
This reverts commit 37ee0f5e594dd772ec6d620b5e5ea8a751b684f0.
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}
Uppercase constants are more likely to conflict with macros (for
example rtc::SRTP_AES128_CM_SHA1_80 and OpenSSL SRTP_AES128_CM_SHA1_80).
This CL renames some constants and follows the C++ style guide.
Bug: webrtc:12997
Change-Id: I2398232568b352f88afed571a9b698040bb81c30
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226564
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34553}
Reland of commit a743303211b89bbcf4cea438ee797bbbc7b59e80
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
- Mark FindHeaderExtensionByUri without filter argument as deprecated
Bug: webrtc:11713
Change-Id: I52a5ade1b94bc01d1c2a35cb56023684fcaf9982
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219081
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34129}
In this CL, JsepTransportController and MediaSessionDescriptionFactory
are updated not to assume that there only exists at most a single BUNDLE
group but a list of N groups. This makes it possible to create multiple
BUNDLE groups by having multiple "a=group:BUNDLE" lines in the SDP.
This makes it possible to have some m= sections in one group and some
other m= sections in another group. For example, you could group all
audio m= sections in one group and all video m= sections in another
group. This enables "send all audio tracks on one transport and all
video tracks on another transport" in Unified Plan. This is something
that was possible in Plan B because all ssrcs in the same m= section
were implicitly bundled together forming a group of audio m= section and
video m= section (even without use of the BUNDLE tag).
PeerConnection will never create multiple BUNDLE groups by default, but
upon setting SDP with multiple BUNDLE groups the PeerConnection will
accept them if configured to accept BUNDLE. This makes it possible to
accept an SFU's BUNDLE offer without having to SDP munge the answer.
C++ unit tests are added. This fix has also been verified manually on:
https://jsfiddle.net/henbos/to89L6ce/43/
Without fix: 0+2 get bundled, 1+3 don't get bundled.
With fix: 0+2 get bundled in first group, 1+3 get bundled in second
group.
Bug: webrtc:10208
Change-Id: Iaf451fa5459c484730c8018274166ef154b19af8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214487
Reviewed-by: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33838}
Since there is only a single type of DataChannel now, the enum was only used
when data channels were disabled at the PC API. That option has been
deprecated 4 years ago, it's now time to remove it.
Bug: webrtc:6625
Change-Id: I9e4ada1756da186e9639dd0fbf0249c55ea0b6c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215661
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33778}
This reverts commit a743303211b89bbcf4cea438ee797bbbc7b59e80.
Reason for revert: Breaks downstream tests that attempt to call FindHeaderExtensionByUri with 2 arguments. Could you keep the old 2-argument method declaration and just forward the call to the new 3-argument method with a suitable no-op filter?
Original change's description:
> Fix RTP header extension encryption
>
> Previously, RTP header extensions with encryption had been filtered
> if the encryption had been activated (not the other way around) which
> was likely an unintended logic inversion.
>
> In addition, it ensures that encrypted RTP header extensions are only
> negotiated if RTP header extension encryption is turned on. Formerly,
> which extensions had been negotiated depended on the order in which
> they were inserted, regardless of whether or not header encryption was
> actually enabled, leading to no extensions being sent on the wire.
>
> Further changes:
>
> - If RTP header encryption enabled, prefer encrypted extensions over
> non-encrypted extensions
> - Add most extensions to list of extensions supported for encryption
> - Discard encrypted extensions in a session description in case encryption
> is not supported for that extension
>
> Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
> into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
> header extensions will prevent any RTP packets being sent/received.
>
> Bug: webrtc:11713
> Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Taylor <deadbeef@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33723}
TBR=deadbeef@webrtc.org,terelius@webrtc.org,hta@webrtc.org,lennart.grahl@gmail.com
Change-Id: I7df6b0fa611c6496dccdfb09a65ff33ae4a52b26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11713
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215222
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33727}
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
header extensions will prevent any RTP packets being sent/received.
Bug: webrtc:11713
Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33723}
The extmap-allow-mixed SDP attribute signals that one- and two-byte RTP
header extensions can be mixed. In practice, this also means that WebRTC
will support two-byte RTP header extensions when this is signaled by
both peers.
Bug: webrtc:9985
Change-Id: I80a3f97bab162c7d9a5acf2cae07b977641c039d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/197943
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33036}
otherwise if the client receives a flexfec-enabled offer
and receiving flexfec is enabled by default, an answer
or subsequent offer will enable sending flexfec.
BUG=webrtc:8151
Change-Id: I632094f69ffa68518b6b8f31175eb093efaf51c6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/193862
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/master@{#32628}
the limit is ignored anyway. Also rename rtp datachannel
bandwidth limit constant.
BUG=webrtc:6625
Change-Id: If7b26691ced8148955e98c86b9bed692b2e55e8e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189972
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32479}
This is a reland of 11dc6571cb4ff3e71dee1557dfff8d9076e108d3
One fix that makes Web Platform Tests pass in debug mode is applied.
Original change's description:
> Implement transceiver.stop()
>
> This adds RtpTransceiver.StopStandard(), which behaves according to
> the specification at
> https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-stop
>
> It modifies RTCPeerConnection.getTransceivers() to return only
> transceivers that have not been stopped.
>
> Rebase of armax' https://webrtc-review.googlesource.com/c/src/+/172762
>
> Bug: chromium:980879
> Change-Id: I7d383ee874ccc0a006fdcf280496b5d4235425ce
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180580
> Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
> Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31893}
Bug: chromium:980879
Change-Id: Ide31d929ac5ea118d83fdf6a35a592af23f7dfa7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/181263
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31907}
This reverts commit 11dc6571cb4ff3e71dee1557dfff8d9076e108d3.
Reason for revert: Breaks Chromium WPT tests
Original change's description:
> Implement transceiver.stop()
>
> This adds RtpTransceiver.StopStandard(), which behaves according to
> the specification at
> https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-stop
>
> It modifies RTCPeerConnection.getTransceivers() to return only
> transceivers that have not been stopped.
>
> Rebase of armax' https://webrtc-review.googlesource.com/c/src/+/172762
>
> Bug: chromium:980879
> Change-Id: I7d383ee874ccc0a006fdcf280496b5d4235425ce
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180580
> Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
> Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31893}
TBR=sakal@webrtc.org,kthelgason@webrtc.org,hta@webrtc.org,guidou@webrtc.org,marinaciocea@webrtc.org
Change-Id: Ibdc24f7d41e481293ca74ba6d1572de64f7e4654
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:980879
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/181262
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31897}
This adds RtpTransceiver.StopStandard(), which behaves according to
the specification at
https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiver-stop
It modifies RTCPeerConnection.getTransceivers() to return only
transceivers that have not been stopped.
Rebase of armax' https://webrtc-review.googlesource.com/c/src/+/172762
Bug: chromium:980879
Change-Id: I7d383ee874ccc0a006fdcf280496b5d4235425ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/180580
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31893}
It was used only to provide parameters for MediaTransport.
Bug: webrtc:9719
Change-Id: I42e451ef84251ecf2b15010c7a3923b6fa2436be
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177350
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31541}
This reverts commit 71db9acc4019b8c9c13b14e6a022cbb3b4255b09.
Reason for revert: breaks downstream project.
Reason for force push: win bot broken.
Original change's description:
> RtpTransceiverInterface: introduce SetOfferedRtpHeaderExtensions.
>
> This change adds exposure of a new transceiver method for
> modifying the extensions offered in the next SDP negotiation,
> following spec details in https://w3c.github.io/webrtc-extensions/#rtcrtptransceiver-interface.
>
> Features:
> - The interface allows to control the negotiated direction as
> per https://tools.ietf.org/html/rfc5285#page-7.
> - The interface allows to remove an extension from SDP
> negotiation by modifying the direction to
> RtpTransceiverDirection::kStopped.
>
> Note: support for signalling directionality of header extensions
> in the SDP isn't implemented yet.
>
> https://chromestatus.com/feature/5680189201711104.
> Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/65YdUi02yZk
>
> Bug: chromium:1051821
> Change-Id: Iaabc34446f038c46d93c442e90c2a77f77d542d4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176408
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Markus Handell <handellm@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31487}
TBR=hta@webrtc.org,handellm@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
No-Try: true
Bug: chromium:1051821
Change-Id: I70e1a07225d7eeec7480fa5577d8ff647eba6902
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177103
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31516}
This reverts commit 8e8b36a94a7a7a1fd0f8093979a406afa56e18c1.
Reason for revert: The CL has been improved with the following changes,
- Fixed negotiation of send/receive only clients.
- Handles the implicit assumption that any H264 decoder also can
decode H264 constraint baseline.
Original change's description:
> Distinguish between send and receive codecs
>
> Even though send and receive codecs may be the same, they might have
> different support in HW. Distinguish between send and receive codecs
> to be able to keep track of which codecs have HW support.
>
> Bug: chromium:1029737
> Change-Id: Id119560becadfe0aaf861c892a6485f1c2eb378d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165763
> Commit-Queue: Johannes Kron <kron@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30284}
Change-Id: I834ed48ee78d04922c73e2836165e476925e1cc5
Bug: chromium:1029737
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168605
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30932}
One should use a std::unique_ptr to the object, as returned
by Clone() instead, not a naked pointer.
Bug: webrtc:10701
Change-Id: I10ab309207f2cb5aec83a6d09336699ed7b26f50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169342
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30646}
Without exposing it in capabilities:
this extension is not stable enough to expose it by default,
but already in working state so with munge sdp can be experimented with.
Bug: webrtc:10342
Change-Id: I6bac123325a90431e4769e86da79638869e36cfc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168961
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30645}
The change ships GenericDescriptor00 and authentication by default,
but doesn't expose it by default, and makes WebRTC respond to
offers carrying it.
The change adds a unit test for the new semantics.
Tests well in munge-sdp. Frame marking replaced by
http://www.webrtc.org/experiments/rtp-hdrext/generic-frame-descriptor-00
in the offer results in an answer containing the
extension as first entry.
Bug: webrtc:11367
Change-Id: I0ef91b7d4096d949c3d547ece7d6c4d39aa241da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168661
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30542}
