First batch of applying iwyu to the repo.
Done with:
> ./tools_webrtc/iwyu/apply-iwyu api
> git add api/[a-s]*
> python3 gn_autodeps.py ~/local/webrtc/src out/Default
Last step is a custom script I wrote to automatically apply new required
dependencies for target in gn, which saved tons of time manually going
over the files and fixing.
If this is something that interest others, I can submit it as well.
Bug: webrtc:42226242
Change-Id: Id109e77f50835827495bc4512880c4ec9ae175f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343680
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Dor Hen <dorhen@meta.com>
Cr-Commit-Position: refs/heads/main@{#42512}
Add ulpfec and flexfec to list of resiliency mechanisms taken
into account and in general exclude Comfort Noise (CN) from media
codecs.
Also introduce RtpCodecCapability::IsMediaCodec & ::IsResiliencyCodec
behaving like the MediaCodec methods.
BUG=webrtc:15396
Change-Id: I79041898928190bfdd33a06d8f6975d7556c46b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330424
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@{#41485}
This creates the RtpCodec structure for the common fields
used in RtpCodecParameters and RtpCodecCapability.
Remove the unused fields from both that were defined from ORTC
and never implemented as well.
Bug: webrtc:15064
Change-Id: I37b4c83e2051a888fc99cc0d9f7aeb8d74f0421d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301182
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39862}
With these changes, we now often have 0 invokes and at most 1 when
calling SetLocalContent on a channel. Before we had at least 1 and
typically 2.
Summary of changes.
* Updating RtpExtension::DeduplicateHeaderExtensions to return a sorted
vector (+test) for easy detection of changes.
* Before updating the transport on the network thread, detect if
actual changes to the demuxer criteria or changes to the rtp header
extensions have been made.
* Consolidate both transport updates to a single call instead of two.
* Added DCHECK guards to catch regressions in number of invokes.
A possible upcoming improvement is to update the transport
asynchronously.
Bug: webrtc:13536
Change-Id: I71ef7b181635a796ffa1e3a02a0f661d28a4870c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244700
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35638}
this variant was deprecated 6 month ago in
https://webrtc-review.googlesource.com/c/src/+/219081
with a trivial replacement.
Bug: None
Change-Id: Ib9cd686280edf36da5f39e8e22b6073530837147
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238983
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35421}
Reland of commit a743303211
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}
This reverts commit a743303211.
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}
And use it in a few places that were using RTC_CHECK(false) or FATAL()
to do the exact same job. There should be no change in behavior.
Bug: none
Change-Id: I36d5e6bcf35fd41534e08a8c879fa0811b4f1967
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/191963
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32567}
"warning: control reaches end of non-void function [-Wreturn-type]"
Reported by gcc (8.3)
In all the reported cases, the end of function is never actually
reached. Add RTC_CHECK(false) to ensure the compiler is aware that
this path is a dead-end.
Bug: webrtc:12008
Change-Id: I7f816fde3d1897ed2774057c7e05da66e1895e60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189784
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Fabien VALLÉE <fabien.vallee@netgem.com>
Cr-Commit-Position: refs/heads/master@{#32503}
This should help debugging when adaptation is or is not happening
unexpectedly. Log spam is prevented by not logging if the same
result happened to the same resource already and we haven't
adapted since then.
Bug: webrtc:11616
Change-Id: Ia6c5cc35061d252f1c66f2f2bf3b94d2485498d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176221
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31378}
To allow construct that object from an existent string_view without explicit conversion
Bug: webrtc:11428
Change-Id: I38d93573be72e307bdf7068a6300d10cf46d2d62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171689
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30904}
This CL replaces a few usages of const std::string& with
absl::string_view, to comply closer with
https://abseil.io/tips/1.
Bug: webrtc:11428
Change-Id: Ibf6fac9b084cb21e17db63f73d667793ab9cafeb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/170466
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30845}
This change adds exposure of a new transceiver method for getting
the total set of supported extensions stored as an attribute,
and their direction. If the direction is kStopped, the extension
is not signalled in Unified Plan SDP negotiation.
Note: SDP negotiation is not modified by this change.
Changes:
- RtpHeaderExtensionCapability gets a new RtpTransceiverDirection,
indicating either kStopped (extension available but not signalled),
or other (extension signalled).
- RtpTransceiver gets the new method as described above. The
default value of the attribute comes from the voice and video
engines as before.
https://chromestatus.com/feature/5680189201711104.
go/rtp-header-extension-ip
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/65YdUi02yZk
Bug: chromium:1051821
Change-Id: I440443b474db5b1cfe8c6b25b6c10a3ff9c21a8c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/170235
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30800}
This does not add it in default SDP offer.
Bug: webrtc:10739
Change-Id: I4e73f4497989fc34f3676927921a4dabb5926096
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169729
Commit-Queue: Minyue Li <minyue@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30707}
It can only be one of four possible values, so it never made sense
for it to be a double. Other than the fact that its neighbor
bitrate_priority is a double, and they're both defined as the same enum
in the web spec. However, while bitrate_priority being a double
offers more flexibility than the web spec, network_priority being a
double is only confusing.
Bug: webrtc:5658
Change-Id: I0784c116f3260c4b3a8b99a3cd85c8d66017e46f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168840
Reviewed-by: Anders Carlsson <andersc@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30685}
This matches the web API more, since the equivalent type there is named
RTCPriorityType.
Bug: webrtc:5658
Change-Id: I301fed8319f7e582b558fe7cd0deee1290708c4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169040
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30613}
After chromium switches to using these, they'll be changed to an enum.
Bug: webrtc:5658
Change-Id: Ic5d7d4651d204c31822194bd02c587e5b887ee17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168562
Commit-Queue: Taylor <deadbeef@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30551}
This change adds the writing and parsing of the `abs-capture-time` RTP header extension defined at:
http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time
We are still missing the code to:
- Negotiate the header extension.
- Collect capture time for audio and video and have the info sent with the header extension.
- Receive the header extension and use its info.
Bug: webrtc:10739
Change-Id: I75af492e994367f45a5bdc110af199900327b126
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144221
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Chen Xing <chxg@google.com>
Cr-Commit-Position: refs/heads/master@{#28468}
Bug: None
Change-Id: I87439a234d7018757eb61e99d5c6f9c7be4ab357
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128825
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27272}
The previous URI was a placeholder and is not valid. The URI
https://webrtc.org/experiments/rtp-hdrext/transport-wide-cc-02/
must be used instead.
Bug: webrtc:10264
Change-Id: Ibabde599b5bbd116c1c5e86ba0c9c64019bf7026
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126360
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27051}
One-byte RTP extensions may only have IDs in the range 1-14.
For higher IDs, the two-byte format must be used.
If default IDs are set for all extensions, once 15 extensions are
defined by the code, some extensions will have IDs greater than 14.
This will happen even if only one extension actually ends up being
offered, so long as it's that unfortunate RTP extension.
It's better to dynamically assign the IDs to those extensions we
actually offer. The code that assigns the IDs is currently
distributed ( WebRtcVoiceEngine::GetCapabilities() and
WebRtcVideoEngine::GetCapabilities()), and without a bigger
refactoring effort would produce some ID collisions and mismatches.
Those are already handled by MergeRtpHdrExts(), so so that
should not be a problem.
Bug: webrtc:10288
Change-Id: I087f1ed5baa9fd61fd5556f1d82f540304ec6b93
Reviewed-on: https://webrtc-review.googlesource.com/c/122480
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26876}
TransportSequenceNumberV2 is an experimental feature that should
not be part of the default offer. However, if we receive an offer
with this extension we should respond that we support it.
Bug: webrtc:10264
Change-Id: Id2424d421361e5d71f3a608cb8f74b63645c264a
Reviewed-on: https://webrtc-review.googlesource.com/c/123783
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26817}
The discardability flag denotes whether the frame may be dropped by
the decoder with no effect on the decodability of subsequent frames.
Bug: webrtc:10214
Change-Id: I3654951d8863b50effe9670b8d1d7eb051240039
Reviewed-on: https://webrtc-review.googlesource.com/c/122241
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26763}
