Static libraries don't guarantee that an exported symbol gets linked
into a shared library (and in order to support Chromium's component
build mode, WebRTC needs to be linked as a shared library).
Source sets always pass all the object files to the linker.
On the flip side, source_sets link more object files in release builds
and to avoid this, this CL introduces a the GN template "rtc_library" that
expands to static_library during release builds and to source_set during
component builds.
See: https://gn.googlesource.com/gn/+/master/docs/reference.md#func_source_set
Bug: webrtc:9419
Change-Id: I4667e820c2b3fcec417becbd2034acc13e4f04fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157168
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#29525}
Post-pacer code now contained in RtpSenderEgress class.
For now, this is a member of RTPSender. More refactoring is needed to
make clean split.
Bug: webrtc:11036
Change-Id: I95264d013de120601784f130ba81c7b234446980
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157172
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29519}
We should reject invalid values explicitly in order to prevent DCHECK
failures later, which affect fuzzing progress.
Bug: chromium:1009172, chromium:1009073
Change-Id: I7f0dc417ecac7aab076a652143f5face2ff98da2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156340
Commit-Queue: Kuang-che Wu <kcwu@google.com>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29459}
There are a few reasons for making this test only:
* The code is only used by tests and utilities.
* The pure interface has only a single implementation so an interface isn't really needed.
(a followup change could remove it altogether)
* The implementation always incorporates locking regardless of how the class gets used.
See e.g. previous use in the Packet class.
* The implementation is a layer on top of RtpUtility::RtpHeaderParser which is
sufficient for most production cases.
Change-Id: Ide6d50567cf8ae5127a2eb04cceeb10cf317ec36
Bug: none
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150658
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29010}
The new target does not depend on libjingle_peerconnection_api, and to
do this, the named "audio" and "video" string literals had to be moved from
media_stream_interface.cc to media_types.cc.
In this cl, the dependency on libjingle_peerconnection_api can be
dropped from a few targets.
No-Presubmit: True
Bug: webrtc:8733
Change-Id: Icc675280d5c3c537f2255a9389ff18a482049921
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/53861
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28998}
This change adds helper classes to manipulate Absolute Capture Time header extensions. Both classes support the "timestamp interpolation" optimization.
Bug: webrtc:10739
Change-Id: I08eff46eb8910842a6dbaa3288b976004fabe1c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149801
Commit-Queue: Chen Xing <chxg@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28936}
This change removes the old `ContributingSources` class. It has been replaced by the new `SourceTracker`.
Bug: webrtc:10793
Change-Id: Ibd481cf6584837c46b229b9fc2a071362f07d361
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147878
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Chen Xing <chxg@google.com>
Cr-Commit-Position: refs/heads/master@{#28756}
This adds the RemoteEstimate rtcp packet and wires it up to GoogCC where
it's used to improve congestion controller behavior.
The functionality is negotiated using SDP.
It's added with a field trial that allow disabling the functionality in
case there's any issues.
Bug: webrtc:10742
Change-Id: I1ea8e4216a27cd2b00505c99b42d1e38726256c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/146602
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28654}
This CL just adds the new interfaces, follow-ups will add implementation
in various parts of the code, and then do cleanup once usage of old
interface is gone.
Bug: webrtc:10633
Change-Id: Icd916f4220065c0d0e4f3f0bfaaed248f8c70d08
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140891
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28252}
This change adds a new SourceTracker class that can do spec-compliant tracking of RTCRtpContributingSource and RTCRtpSynchronizationSource when frames are delivered to the RTCRtpReceiver's MediaStreamTrack for playout. It will replace the existing spec-incompliant ContributingSources.
Bug: webrtc:10545 webrtc:10668
Change-Id: I961adaba09d6337f2f36b301a4fabcd20de65271
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140948
Commit-Queue: Chen Xing <chxg@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28249}
This method will be used instead of GetPacketAndSetSendTime() when the
new pacer code path is used, where the packet isn't stored in the
history during pacing.
Bug: webrtc:10633
Change-Id: Ie168125d949cef617ade3868a1858ed1dffe909c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140892
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28240}
This change is part of a change to break the dependency between "api:rtp_headers" and "api/video:video_frame". It does so by first creating an empty "api/video:video_rtp_headers" build rule so that downstream projects can be fixed before moving the source files.
Bug: webrtc:10668
Change-Id: I81aa6edfef3639b457a40aa93de048e62cbfd8ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140291
Commit-Queue: Chen Xing <chxg@google.com>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28209}
The ReportBlockData contains information about a ReportBlock and
additional data such as RTT. This will be used for the calculation of
RTCRemoteInboundRtpStreamStats, see full picture here:
https://webrtc-review.googlesource.com/c/src/+/134107
ReportBlockData is a class version of the previously internal struct
RTCPReceiver::ReportBlockWithRtt.
- The new name makes sense even if we add more info to it, which will
be needed for future metrics.
- The new location is modules/rtp_rtcp/include/report_block_data.h.
The RTCPReceiver allows obtaining the ReportBlockData in two ways:
1. Using a ReportBlockDataObserver that is notified on receiving a
report block.
2. Using the GetLatestReportBlockData().
Both codepaths will be needed; video stats uses observers and audio
stats uses polling.
Further plumbing will be done in follow-up CLs.
Bug: webrtc:10455, webrtc:10456
Change-Id: Ic9e5b4f451b5f4b203efcd6fa3bbf9736487e1f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/136584
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27961}
The latter is also a member of the former. This cleanup is also
a preparation for dropping WebRtcRTPHeader::frameType (or deleting
WebRtcRTPHeader right away), now that it's a video-specific member.
Tbr: kwiberg@webrtc.org # Comment change in modules/include/
Bug: None
Change-Id: I5c1f3f981f0d750713fc9b9b145278150fe32b5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133024
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27740}
The video encoder should be informed of incoming LossNotification
RTCP messages. Since it is unaware of RTP sequence numbers,
or anything else RTP-related, the sequence numbers mentioned
in the RTCP message must first be mapped to timestamps,
since those are meaningful to the encoder.
This CL introduces RtpSequenceNumberMap, which maps RTP sequence
numbers to timestamps, while providing:
1. Capping the number of entries.
2. Wrap-around handling.
RtpSequenceNumberMap also remembers which packets were first
and/or last in the frame.
Later CLs will wire this up.
Bug: webrtc:10501
Change-Id: Ie0662cdb5706a3bcf63aa2934816a9df88439357
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130497
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27448}
And delete corresponding dependencies on :webrtc_common. After this
change, common_types.h is included directly only from code in the
following directories:
api/
api/video/
api/video_codecs/
common_video/libyuv/include/
media/base/
modules/remote_bitrate_estimator/
modules/rtp_rtcp/source/
modules/video_coding/codecs/vp9/
There remains plenty of indirect dependencies on the types declared in
common_types.h, but the fewer direct dependencies should make it
easier to find the proper place for each type.
Bug: webrtc:5876
Change-Id: I93e8f214025ecb613c19fdec2015bd3f96c59aae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130501
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27376}
Replaces use of field trials in RtpSender and RtpVideoSender with injectable WebRtcKeyValueConfig.
Implementation still defaults to field trials.
BUG: webrtc:10335
Change-Id: I5fc6d327ee5d011ccc41385734b38344df172627
Reviewed-on: https://webrtc-review.googlesource.com/c/123447
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26795}
Also refactor most of the RtpSender tests to not use the frame-level
method RTPSender::SendOutgoingData.
Bug: webrtc:7135
Change-Id: I9b0af6aa45e9b908d8197e48b143fede7e2804c7
Reviewed-on: https://webrtc-review.googlesource.com/c/121461
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26577}
Update RtpSenderAudioTest to call methods on RTPSenderAudio rather
than RTPSender, when possible. In particular, avoid
RTPSender::SendOutgoingData. Drop parameterization on the
WebRTC-SendSideBwe-WithOverhead field trial, since that appears
unrelated to these tests.
Also delete some unused parts of the RtpSender test.
Bug: webrtc:7135
Change-Id: I535bf48bb1720e2727f4a62fa3e49b2bb84394a0
Reviewed-on: https://webrtc-review.googlesource.com/c/120920
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26516}
Create a new RTCP feedback message for reporting the loss and/or non-decodability of video frames, to be used by the upcoming injectable VideoFrameBufferController. The new feedback message should report:
1. The sequence number of the last decoded non-discardable video frame. (TBD: If a multi-packet frame, should it be the sequence number of the first, last, or any of the packets?)
2. The sequence number of the last received RTP packet in the stream.
3. A decodability flag, whose specific meaning depends on the last-received
RTP sequence number. The decodability flag is true if and only if all of
the frame's dependencies are known to be decodable, and the frame itself
is not yet known to be unassemblable.
* Clarification #1: In a multi-packet frame, the first packet's
dependencies are known, but it is not yet known whether all parts
of the current frame will be received.
* Clarification #2: In a multi-packet frame, the dependencies would be
unknown if the first packet was not received. Then, the packet will
be known-unassemblable.
Bug: webrtc:10226
Change-Id: I1563c944477e3ed40235e82ab99a439414632aff
Reviewed-on: https://webrtc-review.googlesource.com/c/118931
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26387}
This CL adds a single class to manage the use case of having a task
that repeats itself by a fixed or variable interval. It replaces the
repeating task previously locally defined for rtp transport controller
send as well as the cancelable periodic task. Furthermore, it is
introduced where one off repeating tasks were created before.
It provides the currently used functionality of the cancelable periodic
task, but not some of the unused features, such as allowing cancellation
of tasks before they are started and cancellation of a task after the
owning task queue has been destroyed.
Bug: webrtc:9883
Change-Id: Ifa7edee836c2a64fce16a7d0f682eb09c879eaca
Reviewed-on: https://webrtc-review.googlesource.com/c/116182
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26313}
kMaxSimulcastStreams, kMaxSpatialLayers and kMaxTemporalStreams don't
really beling on VideoBitrateAllocation.
common_types.h is going away and it feels dubious to requrie include
of the full VideoEncoder api to use them. Therefore moving them into a
seprate file/target.
Also includes some remaining cleanup of includes.
Bug: webrtc:9271
Change-Id: I7ded3d97a9a835ac756159700774445a2b93a697
Reviewed-on: https://webrtc-review.googlesource.com/c/117305
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26299}
