Update libwertc AudioRtpSender::SetAudioSend with WEBRTC_WEBKIT_BUILD
This only introduces the WEBRTC_WEBKIT BUILD, inspired by WEBRTC_CHROMIUM_BUILD
macro. It is only defined by Webkit libwebrtc build system.
https://trac.webkit.org/changeset/210977
BUG=webrtc:7039
Review-Url: https://codereview.webrtc.org/2651273003
Cr-Commit-Position: refs/heads/master@{#16432}
Fix: Order of assignments is now correct, after being incorrect
due to an incorrect merge between
https://codereview.webrtc.org/2617373002/ and
https://codereview.webrtc.org/2589713003.
Improvement: Set parameters in more places, allowing for
correct reconfiguration. Add TODOs to point of minor issues
with current configuration.
TESTED=By locally patching an application using this code.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2660403004
Cr-Commit-Position: refs/heads/master@{#16431}
The timer is only used for logging purposes and we can save CPU by
checking the volume less often.
BUG=webrtc:7096
Review-Url: https://codereview.webrtc.org/2669323003
Cr-Commit-Position: refs/heads/master@{#16430}
We have seen that PostTask can consume some CPU and the way we used it
before (logging only) in the ADB is not worth the cost we see when
profiling.
This CL simply moves frequent (trivial) stat updates from the task queue
to the native threads to avoid calling PostTask in each callback.
The reason for doing so before was to avoid locks but we can live without
them since races are benign here.
BUG=webrtc:7096
Review-Url: https://codereview.webrtc.org/2663383004
Cr-Commit-Position: refs/heads/master@{#16429}
This CL replaces the previously-hardcoded DTLS timeout value of 50 ms with one that is picked dynamically as 2x ICE RTT (clamped between 50 and 3000 ms to keep it reasonable).
No tests yet - I'm working on these, but sending out this CL early to get feedback. I've tested it manually and on slow networks it results in successful DTLS setup in a single attempt - instead of clogging up the slow link with multiple retransmissions as done previosly.
BUG=webrtc:7099
Review-Url: https://codereview.webrtc.org/2670113002
Cr-Commit-Position: refs/heads/master@{#16426}
As it is, the test fails to compile on some downstream compilers with the following error:
webrtc/modules/audio_coding/neteq/neteq_impl_unittest.cc:316:25: error: lambda capture 'kPayloadLength' is not required to be captured for this use [-Werror,-Wunused-lambda-capture]
.WillOnce(Invoke([kPayloadLength, kFirstSequenceNumber, kFirstTimestamp,
^
webrtc/modules/audio_coding/neteq/neteq_impl_unittest.cc:316:41: error: lambda capture 'kFirstSequenceNumber' is not required to be captured for this use [-Werror,-Wunused-lambda-capture]
.WillOnce(Invoke([kPayloadLength, kFirstSequenceNumber, kFirstTimestamp,
^
webrtc/modules/audio_coding/neteq/neteq_impl_unittest.cc:316:63: error: lambda capture 'kFirstTimestamp' is not required to be captured for this use [-Werror,-Wunused-lambda-capture]
.WillOnce(Invoke([kPayloadLength, kFirstSequenceNumber, kFirstTimestamp,
^
webrtc/modules/audio_coding/neteq/neteq_impl_unittest.cc:317:25: error: lambda capture 'kFirstReceiveTime' is not required to be captured for this use [-Werror,-Wunused-lambda-capture]
kFirstReceiveTime](const SdpAudioFormat& format,
BUG=webrtc:7107
Review-Url: https://codereview.webrtc.org/2672823002
Cr-Commit-Position: refs/heads/master@{#16422}
If an application sets a non-null value in RTCConfiguration.iceCheckMinInterval, we do not sent STUN pings more often than that. This is useful for bandwidth constrained scenarios.
This CL also increases the maximum STUN ping timeout to 60 seconds up from its previous value of 5 (which meant that a ping response received 5 seconds later would not be counted), and allows the RTT estimate to go up to 60 seconds from its previous limit of 3. RTTs above 3 seconds are possible on mobile links. (webrtc:7109)
This CL was originally written by pthatcher@, I am just submitting it after a minor cleanup.
BUG=webrtc:7082, webrtc:7109
Review-Url: https://codereview.webrtc.org/2670053002
Cr-Commit-Position: refs/heads/master@{#16421}
Since we can't know when a H264 frame really starts we instead group all packets together by timestamp when a frame seems to be complete (only in the case of H264).
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2675693002
Cr-Commit-Position: refs/heads/master@{#16419}
Proper error handling was missing, using VERIFY to crash in debug
builds, while release builds would ignore the error and leak the
attribute memory. The check of attribute type consistency was changed
to a RTC_DCHECK.
Also removes a large number of uses of the deprecated VERIFY macro.
BUG=webrtc:6424
Review-Url: https://codereview.webrtc.org/2665343002
Cr-Commit-Position: refs/heads/master@{#16413}
Adds ignore for all lint errors in Chromium code. Changes minimum SDK for
instrumentation tests to 16 from 14. Adds TargetApi annotations.
BUG=webrtc:6597
Review-Url: https://codereview.webrtc.org/2670473004
Cr-Commit-Position: refs/heads/master@{#16412}
It's currently not possible on Mac and iOS due to libtool. See webrtc:6418
for more info.
BUG=webrtc:6418
NOTRY=True
Review-Url: https://codereview.webrtc.org/2367313002
Cr-Commit-Position: refs/heads/master@{#16411}
Previously in the spec, there was a createDtmfSender method on
PeerConnection, but that's been replaced by a "dtmf" attribute
on RtpSender, which allows getting a DTMF sender without having
an audio track.
This also simplifies the code slightly, since tracks are now not
necessary for identification.
BUG=webrtc:4180
Review-Url: https://codereview.webrtc.org/2666853002
Cr-Commit-Position: refs/heads/master@{#16409}
BUG=webrtc:7097
TEST=Set "ptime=120", try WebRTC calls over custom build Chromium with and without Opus 120ms. Try both Chromium w <-> Chromium w and Chromium w <-> Chromium w/o
Review-Url: https://codereview.webrtc.org/2668633004
Cr-Commit-Position: refs/heads/master@{#16408}
Useful if bitrate probing is to be used with audio streams.
BUG=webrtc:7043
Review-Url: https://codereview.webrtc.org/2652893004
Cr-Commit-Position: refs/heads/master@{#16404}
Use AdaptDown/AdaptUp instead of ScaleDown/ScaleUp, since we may want to
adapt using other means than resolution.
Also, extend vie_encoder with unit test that actually uses frames scaled
to resolution as determined by VideoAdapter, since that seems to be the
default implementation.
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2652893015
Cr-Commit-Position: refs/heads/master@{#16402}
Note:
* PLR is calculated over all of the known packets.
* RPLR is calculated over all of the known packet *pairs*. That is, only over sets of subsequent packets where the reception status is known for both.
BUG=webrtc:7058
Review-Url: https://codereview.webrtc.org/2629883003
Cr-Commit-Position: refs/heads/master@{#16401}
(Or, in less flattering terms, fixing a performance issue introduced
a few months ago by me).
In GN release mode (is_debug = false), the version of the mixer code
before this CL generated code that multiplied each sample (tens of
thousands/second for each input stream) with a floating point number.
This number is almost always exactly 1.0f. The only situation when it's
not 1 is when an audio steam is added or removed.
For one input stream early return leads to a 30% improvement of audio
mixing time profiled on x86-64 under a release build (is_debug = false,
enable_profiling, enable_full_stack_frames_for_profiling) with 16kHz and no
APM limiter. There can be up to 3 streams.
BUG=chromium:687502
Review-Url: https://codereview.webrtc.org/2659423002
Cr-Commit-Position: refs/heads/master@{#16396}
Reason for revert:
due to failures on perf tests (not on perf stats, but fails running due to dcheck failures), see e.g., https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20(K%20Nexus5)
Original issue's description:
> Drop frames until specified bitrate is achieved.
>
> This CL fixes a regression introduced with the new quality scaler
> where the video would no longer start in a scaled mode. This CL adds
> code that compares incoming captured frames to the target bitrate,
> and if they are found to be too large, they are dropped and sinkWants
> set to a lower resolution. The number of dropped frames should be low
> (0-4 in most cases) and should not introduce a noticeable delay, or
> at least should be preferrable to having the first 2-4 seconds of video
> have very low quality.
>
> BUG=webrtc:6953
>
> Review-Url: https://codereview.webrtc.org/2630333002
> Cr-Commit-Position: refs/heads/master@{#16391}
> Committed: 83399caec5TBR=perkj@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2666303002
Cr-Commit-Position: refs/heads/master@{#16395}
Delete the calls from RtpStreamReceiver (for video) and
AudioReceiveStream.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2659563002
Cr-Commit-Position: refs/heads/master@{#16393}
This CL fixes a regression introduced with the new quality scaler
where the video would no longer start in a scaled mode. This CL adds
code that compares incoming captured frames to the target bitrate,
and if they are found to be too large, they are dropped and sinkWants
set to a lower resolution. The number of dropped frames should be low
(0-4 in most cases) and should not introduce a noticeable delay, or
at least should be preferrable to having the first 2-4 seconds of video
have very low quality.
BUG=webrtc:6953
Review-Url: https://codereview.webrtc.org/2630333002
Cr-Commit-Position: refs/heads/master@{#16391}
It appears that thread.cc was the only thing in the webrtc codebase that was
doing this incorrectly (platform_thread.cc, for instance, is ok).
BUG=chromium:687251
Review-Url: https://codereview.webrtc.org/2668693005
Cr-Commit-Position: refs/heads/master@{#16387}
