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}
This CL makes the new code path for paced sending functionally complete.
By default, the field trial WebRTC-Pacer-ReferencePackets is Enabled,
meaning that there is no behavior change unless the field trial is
forced to Disabled. This is done in tests, and can be done on the
command line for manual testing.
Bug: webrtc:10633
Change-Id: I0d66c94ef83b5847dee437a785018f09ba3f828d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144050
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28497}
Encountering GL_OUT_OF_MEMORY is relatively common and we should give
clients a chance to deal with it in a non-fatal way.
Bug: webrtc:8154
Change-Id: Ifa9ca74392f21083692b02a5144dc5632a88d34d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144561
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28495}
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}
Add PC level audio quality test as separate file but into the same
binary as low_bandwidth_audio_test.cc
Bug: webrtc:10138
Change-Id: I3bb7df4130ab62c21a82881cd9f57b936f3cc11d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144621
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28493}
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 reverts commit 8fa7151e4bbad40fec1f964fe0c003b8787bb78a.
Reason for revert: Speculative revert to fix roll of webrtc into chrome. Right now tests related to RTCRtpReceiver failing and looks like it is main candidate, who can affect that behavior.
Original change's description:
> Replace the implementation of `GetContributingSources()` on the audio side.
>
> This change replaces the `ContributingSources`-implementation of `GetContributingSources()` and `GetSynchronizationSources()` on the audio side with the spec-compliant `SourceTracker`-implementation.
>
> The most noticeable impact is that the per-frame dictionaries are now updated when frames are delivered to the RTCRtpReceiver's MediaStreamTrack rather than when RTP packets are received on the network.
>
> This change is almost identical to the previous video side change at: https://webrtc-review.googlesource.com/c/src/+/143177
>
> Bug: webrtc:10545
> Change-Id: Ife7f08ee8ca1346099b7466837a3756947085fc5
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144422
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Commit-Queue: Chen Xing <chxg@google.com>
> Cr-Commit-Position: refs/heads/master@{#28459}
TBR=ossu@webrtc.org,chxg@google.com
Change-Id: I5c631d4dcfb39601055ffce9b104f45eea871fd3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10545
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144562
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28478}
This CL adds a number of debug-mode checks for inconsistent state, and
if in release mode will reset the history instead of crashing.
Bug: webrtc:10794
Change-Id: If099a1bb61314177cdad633d0fbdca052cd3a5ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144525
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28475}
DegradationPreference is already available in namespace webrtc so looks
like there is no reason to redeclare it. Also it cause compilation
error with GCC 5.4.0
Bug: webrtc:10792
Change-Id: I814e90000b8692de67ea477ea7d2769a34a14f01
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144523
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28470}
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}
This change replaces the `ContributingSources`-implementation of `GetContributingSources()` and `GetSynchronizationSources()` on the audio side with the spec-compliant `SourceTracker`-implementation.
The most noticeable impact is that the per-frame dictionaries are now updated when frames are delivered to the RTCRtpReceiver's MediaStreamTrack rather than when RTP packets are received on the network.
This change is almost identical to the previous video side change at: https://webrtc-review.googlesource.com/c/src/+/143177
Bug: webrtc:10545
Change-Id: Ife7f08ee8ca1346099b7466837a3756947085fc5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144422
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Chen Xing <chxg@google.com>
Cr-Commit-Position: refs/heads/master@{#28459}
