This reverts commit 3e8ef940fe86cf6285afb80e68d2a0bedc631b9f.
Reason for revert: This CL causes a performance regression in NetEq, see https://bugs.chromium.org/p/chromium/issues/detail?id=982260.
Original change's description:
> Add plumbing of RtpPacketInfos to each AudioFrame as input for SourceTracker.
>
> This change adds the plumbing of RtpPacketInfo from ChannelReceive::OnRtpPacket() to ChannelReceive::GetAudioFrameWithInfo() for audio. It is a step towards replacing the non-spec compliant ContributingSources that updates itself at packet-receive time, with the spec-compliant SourceTracker that will update itself at frame-delivery-to-track time.
>
> Bug: webrtc:10668
> Change-Id: I03385d6865bbc7bfbef7634f88de820a934f787a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139890
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Reviewed-by: Minyue Li <minyue@webrtc.org>
> Commit-Queue: Chen Xing <chxg@google.com>
> Cr-Commit-Position: refs/heads/master@{#28434}
TBR=kwiberg@webrtc.org,stefan@webrtc.org,minyue@webrtc.org,chxg@google.com
Bug: webrtc:10668, chromium:982260
Change-Id: I5e2cfde78c59d1123e21869564d76ed3f6193a5c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145339
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28561}
The GetImplementations function is similar to the GetSupportedFormats function, but instead of providing one SdpVideoFormat per codec it provides one per codec implementation. These SdpVideoFormats can then be tagged so that a certain implementation can be instantiated when CreateVideoEncoder is called.
Bug: webrtc:10795
Change-Id: I79f2380aa03d75d5f9f36138625abf3543c2339d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145215
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28553}
This change removes RTCP Feedback loop if we are using datagram transport by removing transport sequence numbers from RTP packets and recreating RTCP Feedback from Datagram ACKs and Timestamps.
- For outgoing RTP packets, remove transport sequence number and store it with datagram_id. Note that removing transport sequence numbers does not only save 4-8 bytes per packet, but also prevents generation of feedback packets on the receiver side.
- When datagram ACKs, we re-created RTCP feedback with timestamp.
- Replacing previous assumption that datagram_id was the same as packet_id by storing incremental counter of datagram ids (I noticed some packets come without packet_id, which is a bit strange, but easy to support and it's also good not to rely on packet_ids being unique across multiple ssrcs).
Bug: webrtc:9719
Change-Id: Iecfe938ecea1a74e7c9e1484f0e985d72643d4a1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145269
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28542}
Users of webrtc generally should be able to choose own task queue implementation.
Poison avoids accidental dependency of a low level component on the default implementation
Android and ios apis are still de-facto forced to use the default implementation.
Bug: webrtc:10284
Change-Id: I67ecf2317f43ee32b0c9e8a6e69f1e0987cf1914
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144786
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28524}
Ntp timestamps are used for end-to-end delay measurements and can never
go away. The naming and number of timestamp fields in VideoFrame could
change in the future, but capture time in local clock will always be
there on the receive side.
Bug: none
Change-Id: I358689cd8a44b1da8503136b3dd898b936f2d693
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144542
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28498}
There is no public API to create NetworkBehaviorInterface from
BuiltInNetworkBehaviorConfig, so this CL will add direct method, that will
allow downstream projects to use BuiltInNetworkBehaviorConfig for network
emulation.
Bug: webrtc:10138
Change-Id: Iaec3ea17c12bd06b1c0ff3e5bc2b32cc1c4f62f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144628
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28494}
Because of webrtc:10801, we don't actually support 4 simulcast layers but 3.
Until this is fixed, we limit the value to what we can currently handle.
Bug: webrtc:8785
Change-Id: I513b7c8d4c889fa0d80c91adc1c4f874acb86fdc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144625
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28487}
Two new classes are added to WebRTC from Chrome: ChannelMixer and
ChannelMixingMatrix but they are not yet utilized in the audio path for
WebRTC.
The idea is to utilize these new classes when adding support for multi-
channel encoding/decoding in WebRTC/Chrome.
Adds support for a new enumerator call webrtc::ChannelLayout and some
helper methods which maps between channel layout and number of channels.
These parts are also copied from Chrome.
Minor (cosmetic) changes are also done on the AudioFrame to prepare
for upcoming work.
Bug: webrtc:10783
Change-Id: I6cd7a13a3bc1c8bbfa19bc974c7a011d22d19197
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/141674
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28482}
Implements RTCAudioSourceStats members:
- audioLevel
- totalAudioEnergy
- totalSamplesDuration
In this CL description these are collectively referred to as the audio
levels.
The audio levels are removed from sending "track" stats (in Chrome,
these are now reported as undefined instead of 0).
Background:
For sending tracks, audio levels were always reported as 0 in Chrome
(https://crbug.com/736403), while audio levels were correctly reported
for receiving tracks. This problem affected the standard getStats() but
not the legacy getStats(), blocking some people from migrating. This
was likely not a problem in native third_party/webrtc code because the
delivery of audio frames from device to send-stream uses a different
code path outside of chromium.
A recent PR (https://github.com/w3c/webrtc-stats/pull/451) moved the
send-side audio levels to the RTCAudioSourceStats, while keeping the
receive-side audio levels on the "track" stats. This allows an
implementation to report the audio levels even if samples are not sent
onto the network (such as if an ICE connection has not been established
yet), reflecting some of the current implementation.
Changes:
1. Audio levels are added to RTCAudioSourceStats. Send-side audio
"track" stats are left undefined. Receive-side audio "track" stats
are not changed in this CL and continue to work.
2. Audio level computation is moved from the AudioState and
AudioTransportImpl to the AudioSendStream. This is because a) the
AudioTransportImpl::RecordedDataIsAvailable() code path is not
exercised in chromium, and b) audio levels should, per-spec, not be
calculated on a per-call basis, for which the AudioState is defined.
3. The audio level computation is now performed in
AudioSendStream::SendAudioData(), a code path used by both native
and chromium code.
4. Comments are added to document behavior of existing code, such as
AudioLevel and AudioSendStream::SendAudioData().
Note:
In this CL, just like before this CL, audio level is only calculated
after an AudioSendStream has been created. This means that before an
O/A negotiation, audio levels are unavailable.
According to spec, if we have an audio source, we should have audio
levels. An immediate solution to this would have been to calculate the
audio level at pc/rtp_sender.cc. The problem is that the
LocalAudioSinkAdapter::OnData() code path, while exercised in chromium,
is not exercised in native code. The issue of calculating audio levels
on a per-source bases rather than on a per-send stream basis is left to
https://crbug.com/webrtc/10771, an existing "media-source" bug.
This CL can be verified manually in Chrome at:
https://codepen.io/anon/pen/vqRGyq
Bug: chromium:736403, webrtc:10771
Change-Id: I8036cd9984f3b187c3177470a8c0d6670a201a5a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143789
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28480}
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}
In this CL:
- Added WEBRTC_VIDEO_CODEC_ENCODER_FAILURE return code that can
be returned by the encoder wrapper in case of a broken encoder.
- Added EncoderFailureCallback interface that can be called
to request encoder fallback to be performed. Implemented by
WebRtcVideoChannel and called from the VideoStreamEncoder.
- Updated SelectSendVideoCodec to select all compatible codecs instead
of just one.
Bug: webrtc:10795
Change-Id: I87a83fd02e48c40493c930471c06c3d0941031ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140888
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28462}
Previously, FecControllerOverride was passed to
Vp8FrameBufferController::SetFecControllerOverride. Passing to
the factory is a more elegant way, since it's only used when
the controller is constructed.
TBR=kwiberg@webrtc.org
Bug: webrtc:10769
Change-Id: Iae599889e7ca9003e3200c2911239cbb763ee65a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144380
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28443}
First, the existing configuration parameter (use_datagram_transport) is
now optional.
The new field trial has two flag values:
1. Whether to enable the datagram transport (enabled)
2. Whether to use the datagram transport by default (default_value)
The first is a kill-switch. It disables the datagram transport, even
for applications which inject a datagram transport factory and specify
use_datagram_transport = true. This allows applications which hard-code
a datagram transport to switch it off via field trials.
This flag defaults to true, to avoid breaking downstream projects which
already inject and configure a datagram transport. It may be changed to
false after updating downstream to set this field trial flag to true
when required.
The second provides a default value to be used in case the
aforementioned use_datagram_transport parameter is unset. Applications
which explicitly set use_datagram_transport will use that value.
Applications which do not explicitly specify whether or not to use the
datagram transport will use it (or not) according to the default_value
flag.
One goal of this flag is to simplify rollout in applications which
already set field trials based on configuration, but require code
changes for new RTCConfiguration parameters. A second goal is to
provide platforms with a knob to control whether datagram transport is
"opt-in" or "opt-out".
This flag defaults to false, to prevent downstream projects from
unintentionally enabling the datagram tranpsort.
Bug: webrtc:9719
Change-Id: I521a5fa61c992e76e5081118678a1812a261d672
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144184
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28435}
This change adds the plumbing of RtpPacketInfo from ChannelReceive::OnRtpPacket() to ChannelReceive::GetAudioFrameWithInfo() for audio. It is a step towards replacing the non-spec compliant ContributingSources that updates itself at packet-receive time, with the spec-compliant SourceTracker that will update itself at frame-delivery-to-track time.
Bug: webrtc:10668
Change-Id: I03385d6865bbc7bfbef7634f88de820a934f787a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139890
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Commit-Queue: Chen Xing <chxg@google.com>
Cr-Commit-Position: refs/heads/master@{#28434}
The purpose of this interface is to allow VideoEncoder to override
the bandwidth allocation set by FecController in RtpVideoSender.
This CL defines the interface and sends it down to VideoSender.
Two upcoming CLs will:
1. Make LibvpxVp8Encoder pass it on to the (injectable)
FrameBufferController, where it might be put to good use.
2. Modify RtpVideoSender to respond to the message sent to it
via this API.
TBR=kwiberg@webrtc.org
Bug: webrtc:10769
Change-Id: I2ef82f0ddcde7fd078e32d8aabf6efe43e0f7f8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143962
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28416}
This is part of a series of CLs with the goal to make the network
state estimate fields more semantically useful.
Bug: webrtc:10742
Change-Id: I3185dc8c4574710a4dce44a4ffd6cefe0fb4e8cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144036
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Jonas Olsson <jonasolsson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28406}
When provided, these thresholds will be used instead of WebRTC default
limits specified in DropDueToSize() and GetMaxDefaultVideoBitrateKbps().
Bug: none
Change-Id: Ida45ea832041963b8b8475d69114b5c60a172fb7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142170
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Alex Glaznev <glaznev@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28390}
And delete corresponding plumbing via the internal stats attribute
MediaReceiverInfo::fraction_lost. The latter attribute is not deleted
yet, since downstream projects have to be updated first.
Bug: webrtc:10744
Change-Id: Id5401aeee7e5637a406ddf2fa33fbfe336abec9f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143178
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28385}
This is a reland of fa79081dca9faa8322943641352d9d2fd1b1b445
It crashed due to inability to handle small timestamps in probe
estimator. This was fixed by moving history window check to avoid
subtracting from the timestamp.
Original change's description:
> Cleanup of RTP references in GoogCC implementation.
>
> As the send time congestion controller now has been removed,
> we don't need the RTP related constructs anymore.
>
> Bug: webrtc:9510
> Change-Id: I02c059ed8ae907ab4672d183c5639ad459b581aa
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142221
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Reviewed-by: Björn Terelius <terelius@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28330}
Bug: webrtc:9510
Change-Id: I3bf91222068e4fbb6aa159bfeb7a73e00bb6a0d7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143165
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28347}
This change adds the plumbing of RtpPacketInfo from RtpVideoStreamReceiver::OnRtpPacket() to VideoReceiveStream::OnFrame() for video. It is a step towards replacing the non-spec compliant ContributingSources that updates itself at packet-receive time, with the spec-compliant SourceTracker that will update itself at frame-delivery-to-track time.
Bug: webrtc:10668
Change-Id: Ib97d430530c5a8487d3b129936c7c51e118889bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139891
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Chen Xing <chxg@google.com>
Cr-Commit-Position: refs/heads/master@{#28332}
This reverts commit fa79081dca9faa8322943641352d9d2fd1b1b445.
Reason for revert: Breaks downstream project.
Original change's description:
> Cleanup of RTP references in GoogCC implementation.
>
> As the send time congestion controller now has been removed,
> we don't need the RTP related constructs anymore.
>
> Bug: webrtc:9510
> Change-Id: I02c059ed8ae907ab4672d183c5639ad459b581aa
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142221
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Reviewed-by: Björn Terelius <terelius@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28330}
TBR=terelius@webrtc.org,srte@webrtc.org
Change-Id: I562365fc5d1da68326d603338ccc6371114d7e12
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9510
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143164
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28331}
As the send time congestion controller now has been removed,
we don't need the RTP related constructs anymore.
Bug: webrtc:9510
Change-Id: I02c059ed8ae907ab4672d183c5639ad459b581aa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142221
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28330}
Users that would like custom TaskQueueFactory (e.g. chromium) should use
CreateModularPeerConnectionFactory directly
Bug: webrtc:10284
Change-Id: I7ba55a0f21560d4beb71a7f93f6fa70b0fe74931
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142234
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28324}
This change is breaks the dependency between "api:rtp_headers" and "api/video:video_frame".
Bug: webrtc:10668
Change-Id: Ib827de2c0e33809ab1d58338037563aa2fa249bc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140949
Commit-Queue: Chen Xing <chxg@google.com>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28322}
