Packet queue in the paced sender is now based on a priority queue rather than having a separate fifo-queue per priority level. This allows more flexible sorting and cleaner usage.
Packets with earlier capture times are now prioritized higher. In situations with high packet loss, the queue might contain packets from several subsequent frames. Retransmit packets from the earlier frames first, since the later ones will probably be dependent on these.
Also, don't force sending of packets after a certain time of inactivity or when packets grow too old, since this was causing consistent overuse on poor connections. Instead, drop frames in vie encoder if pacer queue is too long.
BUG=
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/27869004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7617 4adac7df-926f-26a2-2b94-8c16560cd09d
Pick up the libvpx roll: https://codereview.chromium.org/674753002
Summary of changes (28d1981..d3db2ff/DEPS):
* third_party/android_tools 36bf7ac..ea50ccc
* third_party/boringssl 7ea8481..751e889
* third_party/icu 8ac906f..d8b2a9d
* third_party/libvpx efe9712..2e5ced5
* third_party/usrsctp/usrsctplib
* tools/gyp 1990:1991
* tools/swarming_client a57d7db..bcb3bc3
Clang is not updated in this roll.
Made the change getchar() --> getc(stdin) as seems like getchar() isn't supported on android anymore.
(getchar() was causing the error: undefined reference to '__srget')
Update rate control parameter in vp9 test.
R=andrew@webrtc.orgTBR=ajm@google.com
Review URL: https://webrtc-codereview.appspot.com/23229004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7598 4adac7df-926f-26a2-2b94-8c16560cd09d
This also marks all virtual overrides of other classes in the same files.
This will make a subsequent change I intend to do safer, where I'll change the
argument types of the base Transport functions, by breaking the compile if I
miss any overrides.
This also highlighted a number of unused functions. I've removed some of these.
TBR=mflodman@webrtc.org, pkasting@chromium.org
BUG=none
TEST=none
Review URL: https://webrtc-codereview.appspot.com/28709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7421 4adac7df-926f-26a2-2b94-8c16560cd09d
RemoteNtpTimeEstimator needed user to give a remote SSRC and it intended to call RtpRtcp module to obtain RTT, to be able to calculate Ntp time.
When RTT cannot be directly obtained from the RtpRtcp module with the specified SSRC, RemoteNtpTimeEstimator would fail.
This change allows RemoteNtpTimeEstimator to calculate NTP with an external RTT estimate.
An immediate benefit is that capture_start_ntp_time_ms_ can be obtained in a Google hangout call.
BUG=
TEST=chromium + hangout call
R=stefan@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24879004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7407 4adac7df-926f-26a2-2b94-8c16560cd09d
Targets must now link with implementation of their choice instead of at "gyp"-time.
Targets linking with libjingle_media:
- internal implementation when build_with_chromium=0, default otherwise.
Targets linking with default render implementation:
- video_engine_tests
- video_loopback
- video_replay
- anything dependent on webrtc_test_common
Targets linking with internal render implementation:
- vie_auto_test
- video_render_tests
- libwebrtcdemo-jni
- video_engine_core_unittests
GN changes:
- Not many since there is almost no test definitions.
Work-around for chromium:
- Until chromium has updated libpeerconnection to link with video_capture_impl and video_render_impl, webrtc target automatically depends on it. This should fix the FYI bots and not require a webrtc roll to fix.
Re-enable android tests by reverting 7026 (some tests left disabled).
TESTED: passes all the bots. If this inadvertently breaks a target please fix the linking rules so the target has the desired implementation linked in.
BUG=3770
R=kjellander@webrtc.org, pbos@webrtc.orgTBR=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19359004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7217 4adac7df-926f-26a2-2b94-8c16560cd09d
into its own targets. Dependencies must link directly with the desired one.
Targets linking with libjingle_media:
- internal implementation when build_with_chromium=0, default otherwise.
Targets linking with default/external capture implementation:
- anything dependent on webrtc_test_common
- anything dependent on video_engine_core
Targets linking with internal capture implementation:
- vie_auto_test
- anything dependent on webrtc_test_renderer
GN changes:
- Not many since there is almost no test definitions.
TESTED: passes all the bots. If this inadvertently breaks a target please fix the linking rules so the target has the desired implementation linked in.
BUG=3768
R=glaznev@webrtc.orgTBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24589004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7209 4adac7df-926f-26a2-2b94-8c16560cd09d
This reverts selected parts of r7014 to enable
rolling WebRTC in Chromium DEPS.
This works around the problem with GYP includes
being processed in the first pass (i.e. variables
cannot be used for paths). Using a dependency with
a path using a variable that is conditioned for
build_with_chromium being 0 or 1 solves the Chromium
build.
These changes will be restored once I've finished
a major GYP refactoring that will break out all
test related code (at least the parts that includes
the Android APK targets) into a separate chain
of GYP targets that are not processed when generating
projects for Chromium (which is why r7014 is breaking
the Chromium build).
BUG=3741
TESTED=Passing compilation of standalone using:
GYP_DEFINES="OS=android component=static_library fastbuild=1 target_arch=arm" webrtc/build/gyp_webrtc
ninja -C out/Debug
Then verified the *_apk targets are generated and compiled.
Passing compilation from a Chromium checkout with third_party/webrtc
directory removed and a new empty third_party/webrtc mapped to the
standalone checkout using:
sudo mount --bind /path/to/trunk/webrtc third_party/webrtc
Then running build/gyp_chromium
I also verified WebRTC GYP targets exist and are able to compile.
R=henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20299004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7040 4adac7df-926f-26a2-2b94-8c16560cd09d
Restructure how the Android APK tests are compiled now
that we have a Chromium checkout available (since r6938).
This removes the need of several hacks that were needed when
building these targets from inside a Chromium checkout.
By creating a symlink to Chromium's base we can compile the required
targets. This also removes the need of the previously precompiled
binaries we keep in /deps/tools/android at Google code.
All the user needs to do is to add the target_os = ["android"]
entry to his .gclient as described at
https://code.google.com/p/chromium/wiki/AndroidBuildInstructions
Before committing this CL, the Android APK buildbots will need
to be updated.
This also solves http://crbug.com/402594 since the apply_svn_patch.py
usage will be similar to the other standalone bots.
It also solves http://crbug.com/399297
BUG=chromium:399297, chromium:402594
TESTED=Locally compiled all APK targets by running:
GYP_DEFINES="OS=android include_tests=1 enable_tracing=1" gclient runhooks
ninja -C out/Release
checkdeps
R=henrike@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22149004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7014 4adac7df-926f-26a2-2b94-8c16560cd09d
Also add more from common.gypi to webrtc.gni.
These GN configs are based on GYP files in r6997.
BUG=3441
TEST=Trybots and local compile using:
gn gen out/Default --args="build_with_chromium=false" && ninja -C out/Default
gn gen out/Default --args="build_with_chromium=false is_debug=true" && ninja -C out/Default
Passed compile from a Chromium checkout with src/third_party/webrtc linked to the webrtc/ dir of a checkout with this patch applied.
R=brettw@chromium.org, glaznev@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/18709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6999 4adac7df-926f-26a2-2b94-8c16560cd09d
Fixes issues where statistics only was reported for the first stream if
configured with simulcast, and in case of RTX the reported statistics was
depending on the order of the report blocks.
Also fixes issues with multiple report blocks in the SendStatisticsProxy and the
RtcpStatisticsCallback. SendStatisticsProxy is now aware of RTX ssrcs, and the
RTCPReceiver is calling the RtcpStatisticsCallback with the correct SSRCs, and
not only the primary stream SSRC.
R=mflodman@webrtc.org, sprang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20149004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6903 4adac7df-926f-26a2-2b94-8c16560cd09d
---
Fixes for re-enabling more MSVC level 4 warnings: webrtc/ edition
This contains fixes for the following sorts of issues:
* Possibly-uninitialized local variable
* Signedness mismatch
* Assignment inside conditional
This also contains a small number of other cleanups to nearby code. In
particular several warning-disables for MSVC are removed because they don't seem
to be necessary (either that warning is not enabled or the code does not trigger
it).
BUG=crbug.com/81439
TEST=none
R=henrika@webrtc.org, pkasting@chromium.org
Review URL: https://webrtc-codereview.appspot.com/18769004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6667 4adac7df-926f-26a2-2b94-8c16560cd09d
