The lowest level and some of the highest levels of this function are
already using ArrayView. Make this consistent throughout.
Use deprecation for the old API rather than deleting it, since upstream
may be using it.
Bug: webrtc:14870
Change-Id: If5e1a6e9802ecf7e8e3ec27befb5167ca9985517
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291706
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39241}
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}
Today, behaviour is decided based on if transport sequence number v2 is
in the SDP answer. But it might be better to decide based on received
packets since it is valid to negotiate both extensions.
Another bonus With this solution is that Call does not need to know
about receive header exensions.
This is an alternative to https://webrtc-review.googlesource.com/c/src/+/291337
Bug: webrtc:7135
Change-Id: Ib75474127d6e2e2029557b8bb2528eaac66979f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291525
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Johannes Kron <kron@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39226}
Allow CSRCs to be modified per-frame in an Encoded Insertable Streams
transform, to support a web API which allows per-frame CSRC
modifications to signal when a JS application has changed the source
of the video which is written into an encoded frame.
Initially only for Video, with Audio support likely to follow later.
Bug: webrtc:14709
Change-Id: Ib34f35faa9cee56216b30eaae42d7e65c78bb9f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291324
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tove Petersson <tovep@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#39214}
RTPVideoHeader is changed to non-const to allow modifying it. We want
to do this when implementing setMetadata() in JavaScript or when
refactoring clone() as "construct + set bytes + setMetadata".
Unblocks
https://chromium-review.googlesource.com/c/chromium/src/+/4164979.
Bug: webrtc:14709
Change-Id: I6089df9c03e9aa33feeb0830dd240dd456cb565e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290981
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39113}
This is now ready for plumbing to Chromium layers.
Once it's exposed in JavaScript (behind flag!) we can evaluate whether
all of this information is really needed or if the information is
superflous (e.g. already contained in the raw bytes).
Bug: webrtc:14709
Change-Id: I3837ef86046704a300ec8a108c8c9477bd91b9ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290884
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39102}
This will allow exposing VP8, VP9 and H264-specific RTP header metadata
in JavaScript (behind a flag).
This information appears to be necessary for cloning
(https://github.com/w3c/webrtc-encoded-transform/issues/161), and
cloning should be the same as "new frame + setMetadata + setBytes",
ergo this should be exposed.
Bug: webrtc:14709
Change-Id: Ie71c05f40689bbd529dc4674a07a87c7910b22d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290880
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39101}
to remove duplicated implementation of these functions between av1 packetizer, av1 depacketizer and video allocation rtp header extension
Bug: None
Change-Id: I30049f31c289bdb9e0aad6520f5145d1f999e635
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290731
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39069}
RtpPacket has CopyOnWriteBuffer and std::vector that can be moved more
efficiently than copied, thus move of the RtpPacket is also more efficient
Bug: None
Change-Id: I5509346e426cd32d0fb0649ef1a6883b7176df1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290726
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39053}
rtc::CopyOnWriteBuffer::SetSize extends buffer with uninitialized memory by design.
It is up to the user of the rtc::CopyOnWriteBuffer to ensure it is initialized.
Bug: chromium:1404299
Change-Id: I41f3f91bf20ff440984d78ed81e01f5db36ff509
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290400
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38972}
rtc::CopyOnWriteBuffer::SetSize extends buffer with uninitialized memory by design.
It is up to the user of the rtc::CopyOnWriteBuffer to ensure it is initialized.
Bug: chromium:1403397
Change-Id: Ic0111a84bda32379770ddb1c7d24bee10d96b7a4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/289041
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38959}
which needs to be taken into account separately if the
primary SSRC has been acknowledged but the RTX SSRC has
not.
If nothing has been acknowledged, mid+rid are sent on the primary SSRC and mid+rrid are sent on the RTX SSRC.
If the primary SSRC has been acknowledged, no extensions are sent on the primary SSRC and mid+rrid are sent on the RTX SSRC.
If both the primary SSRC and the RTX SSRC have been ack'd, no extensions are sent on either primary or RTX SSRC.
BUG=webrtc:13896
Change-Id: Ice251fae23a881ee9c9edc71b5d5c45a32ac76d2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288980
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38949}
Instead of getting header extension mapping from a receiver object, get the mapping from the received packet.
The purpose is to be able to remove extension information from webrtc/call/receive_stream.h.
Header extensions are negotiated per mid, not per receive stream.
The goal is to reduce the number of places where packets are parsed and demuxed.
Bug: webrtc:7135, webrtc:14795
Change-Id: I8944bc06a11dc572d9e14e7d7ee446a841096295
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288968
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38944}
This CL adds functionality to remove packets matching a given SSRC from
the pacer queue, and calls that with any SSRCs used by an RTP module
when that module is removed.
Bug: chromium:1395081
Change-Id: I13c0285ddca600e784ad04a806727a508ede6dcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/287124
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38880}
The CSRC concept is really a frame level concept.
Setting it per sender is a quick hack, and should be minimized.
This function doesn't seem to be used anywhere, so removing it
lessens the chance of confusion.
Bug: webrtc:7135
Change-Id: Ia3c27b5984b153e68bc51d93b03f08f7f867adc0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/286426
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#38822}
The current logic has risks if the encoder queue changes, for example when switching from a hardware encoder to a software encoder, or when switching from two different software implementations. Always using a dedicated task queue simplifies the code and is safer.
Bug: chromium:1395308
Change-Id: I0a576ed2f6e892955e0a519567969474d3b99efd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285882
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38793}
The constructor and SetRtpState calls for ModuleRtpRtcpImpl2 class fail to propagate the RTP timestamp offset of RtpSender class to RtpSenderEgress class. This results in wrong RTP timestamps being propagated in LossNotification messages.
Change-Id: I1d293289a4815de29d9dd15208bb7fd1a682be82
Bug: webrtc:14719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/284824
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Dan Tan <dwtan@google.com>
Cr-Commit-Position: refs/heads/main@{#38768}
This is a pure move/rename. The reason for wanting the tests in
RTPVideoHeader is that it is the GetAsMetadata() function that we are
testing and in a future CL we'll also want to test SetFromMetadata().
// Bots green, no need to wait for the remaining ones, just a move
NOTRY=True
Bug: webrtc:14709
Change-Id: Iecb938e79e7e8d55e208baea190eef4c6730158e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285460
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38764}
Update GetAsMetadata() to include more of the RTPVideoHeader metadata.
The intent is to be able to both get and set all of these from
JavaScript behind a flag.
Planned follow-up CLs:
1. Also get codecs-specifics, starting with VP8.
2. Test refactoring/rename: Move tests to RTPVideoHeaderTest.
3. Add RTPVideoHeader::SetFromMetadata() covering everything gettable.
4. Chrome plumbing.
Bug: webrtc:14709
Change-Id: I78679b9ff4ca749d50f309a1713e71ceabb826dd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285084
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38756}
In preparation of adding RTPVideoHeader::SetFromMetadata() method, the
VideoFrameMetadata construct-from-RTPVideoHeader is replaced by
RTPVideoHeader::GetAsMetadata(). This serves two purposes:
1. Having "GetAs" and "SetFrom" in the same file reduces the risk of
these two methods getting out of sync as we expand its usage.
2. This is necessary to avoid a circular dependency that would
otherwise be introduced by RTPVideoHeader::SetFromMetadata().
Bug: webrtc:14709
Change-Id: I127b3d15f9a8c6af210449a5a50d414c9ba79930
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285080
Reviewed-by: Tony Herre <herre@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38735}
This will clone an encoded video frame into a sender frame,
preserving metadata as much as possible.
Bug: webrtc:14708
Change-Id: I6f68d2ee65ef85c32cc3c142a41346b81ba73533
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/284701
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38733}
Lazily initialize the RTPSenderVideoFrameTransformerDelegate's
encoder_queue_ on either OnTransformedFrame() or TransformFrame(), to
allow apps to write to an encoded insertable stream's writable before
reading from its readable.
Bug: chromium:1393373
Change-Id: I08f11682fa142884b575bb207d7d7044e80bbb9c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/284921
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Auto-Submit: Tony Herre <herre@google.com>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38728}
remove unused support for more than four spatial layer descriptions
of temporal layers
BUG=webrtc:12000
Change-Id: I087bcd020897898636bdf9c838abafa8c73c53f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281320
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38646}
clarifying that the number of temporal layers is limited to
a single byte and moving the format description from the source
to the document.
drive-by editorial fixes
BUG=webrtc:12000
Change-Id: I33f85e0a81e1dc16ef762171c52a79919080e048
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279940
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38523}
The clang pragma have been added to ensure we can still test the code
until usage is gone, and that we can still have the one implementation
compiling without itself tripping on the deprecation errors.
Users of the code will have deprecation warnings or error as intended.
Bug: webrtc:14617
Change-Id: I21dae57c669557d4d218c235c811174a477be080
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281221
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38514}
This metric was always supposed to be the spec's answer to
googBucketDelay, and is defined as "The total number of seconds that
packets have spent buffered locally before being transmitted onto the
network." But our implementation measured the time between capture and
send, including encode time. This is incorrect and yields a much larger
value than expected.
This CL updated the metric to do what the spec says. Implementation-wise
we measure the time between pushing and popping each packet from the
queue (in modules/pacing/prioritized_packet_queue.cc).
The spec says to increment the delay counter at the same time as we
increment the packet counter in order for the app to be able to do
"delta totalPacketSendDelay / delta packetSent". For this reason,
`total_packet_delay` is added to RtpPacketCounter. (Previously, the
two counters were incremented on different threads and observers.)
Running Google Meet on a good network, I could observe a 2-3 ms average
send delay per packet with this implementation compared to 20-30 ms
with the old implementation. See b/137014977#comment170 for comparison
with googBucketDelay which is a little bit different by design -
totalPacketSendDelay is clearly better than googBucketDelay.
Since none of this depend on the media kind, we can wire up this metric
for audio as well in a follow-up:
https://webrtc-review.googlesource.com/c/src/+/280523
Bug: webrtc:14593
Change-Id: If8fcd82fee74030d0923ee5df2c2aea2264600d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280443
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38480}
This new class implements the existing FieldTrialsView interface,
extending it with the verification functionality. For now, the
verification will only be performed if the rtc_strict_field_trials GN
arg is set.
Most classes extending FieldTrialsView today have been converted to
extend from FieldTrialsRegistry instead to automatically perform
verification.
Bug: webrtc:14154
Change-Id: I4819724cd66a04507e62fcc2bb1019187b6ba8c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276270
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38453}
RFC 3550 specifies samples to be the unit while https://w3c.github.io/webrtc-stats/#receivedrtpstats-dict* specifies time. This avoids the need to convert to time in code that reads the jitter value from RtpReceiveStats.
Bug: webrtc:13757
Change-Id: I972996971c58b686babd621ff4e0f5790fdf2cb1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279281
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Lundqvist <tomasl@google.com>
Cr-Commit-Position: refs/heads/main@{#38419}
Instead of re-using the sender task queue, a new task queue will
suffice.
Bug: webrtc:14445
Change-Id: Ia7395ace2f0bb66bf9e76e3783b208f2cd0385dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275771
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38332}
- Propagating `RtpPacketInfo::local_capture_clock_offset`, an
existing field that is related to the abs-capture-timestamp
header extension field `estimated_capture_clock_offset`
- Propagated through `SourceTracker::SourceEntry`
Bug: webrtc:10739, b/246753278
Change-Id: I21d9841e4f3a35da5f8d7b31582898309421d524
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275241
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38129}
