Replace the two versions with a single DownConvertToCodecFormat. As
mentioned in comments, this could be further consolidated with
RemixAndResample but we should write a full audio converter class in
that case.
Along the way:
- Fix the bug present in Channel::Demultiplex with mono input and a
stereo codec.
- Remove the 32 kHz max from the OnDataAvailable path. This avoids a
48 -> 32 -> 48 conversion when VoE is passed 48 kHz audio; instead we
get a straight pass-through to ACM. The 32 kHz conversion is still
needed in the RecordedDataIsAvailable path until APM natively supports
48 kHz.
- Merge resampler improvements from ACM1 to ACM2. This allows ACM to
handle 44.1 kHz audio passed to VoE and was originally done here:
https://webrtc-codereview.appspot.com/1590004
- Reuse the RemixAndResample unit tests for DownConvertToCodecFormat.
- Remove unused functions from utility.cc.
BUG=3155,3000,b/12867572
TESTED=voe_cmd_test using both the OnDataAvailable and
RecordedDataIsAvailable paths, with a captured audio format of all
combinations of {44.1,48} kHz and {1,2} channels, running through all
codecs, and finally using both ACM1 and ACM2.
R=henrika@webrtc.org, turaj@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/11019005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5843 4adac7df-926f-26a2-2b94-8c16560cd09d
The tool RTPanalyze (used to process an input RTP dump into a
text file of RTP header info) was present in both the neteq and
neteq4 folders. This change pulls in changes from the old to the new
and renames the source file and tool to rtp_analyze.
Removing special code for dummy-rtp files (it is supported without
special code), and making the RED payload type settable using flags.
Moving from test/ to tools/ folder.
BUG=2692
R=turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10789004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5832 4adac7df-926f-26a2-2b94-8c16560cd09d
This disables GN use for the moment (Chromium
has disabled it for now but plan to pick up the
work at a later stage). I'm leaving the rest of
the GN stuff in our DEPS since that's how
the Chromium DEPS currently looks like.
Overview of changes in Chrome DEPS:
$ svn diff http://src.chromium.org/chrome/trunk/src/DEPS -r 255773:260462
which can be compared with the output of:
$ svn cat http://webrtc.googlecode.com/svn/trunk/DEPS | grep chromium_deps | sed 's/^ *//' | sort | uniq
in a WebRTC checkout, gives the following relevant changes:
* third_party/android_tools 0582bd:ca3567
* third_party/icu 249466:259309
* third_party/libjpeg_turbo 251747:259851
* third_party/libyuv 979:986
* third_party/nss 254867:259440
* tools/gyp 1860:1880
The following also shows that Clang is upgraded from r198389 to r202554:
$ svn diff http://src.chromium.org/chrome/trunk/src/tools/clang/scripts/update.sh -r 255773:260462
TEST=trybots
BUG=None
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10679004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5822 4adac7df-926f-26a2-2b94-8c16560cd09d
Modify bitrate controller to update bitrate based on process call and not
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5794 4adac7df-926f-26a2-2b94-8c16560cd09d
This triggered an occasional TSAN failure in
CallTest.ReceivesPliAndRecoversWithNack e.g.:
http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1444/steps/memory%20test%3A%20video_engine_tests/logs/stdio
I managed to reproduce this locally and verified that reverting this CL
corrected it.
> Modify bitrate controller to update bitrate based on process call and not
> only whenever a RTCP receiver block is received.
>
> Additionally:
> Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
>
> Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
>
> Did not touch decrease logic, however since it can be triggered more often it
> may decrease much faster and closer to the original written cap of once every
> 300ms + rtt.
>
> Note:
> rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
> bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
>
> BUG=3065
> R=stefan@webrtc.org, mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/10529004TBR=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10079005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5775 4adac7df-926f-26a2-2b94-8c16560cd09d
Camera start is a blocking operation so never a good idea to do on a main
thread, but worse than that is that the guts of WebView appear to be
interacting with capture start in a bad way causing startup to pause for 10s
while a timeout expires. This change eliminates that 10s delay.
R=noahric@google.com
Review URL: https://webrtc-codereview.appspot.com/10449004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5772 4adac7df-926f-26a2-2b94-8c16560cd09d
