Instead of setting bitrates based on codec target settings (which may
have previously been capped by a codec max bitrate), fetch the last
bandwidth allocated for this channel. This fixes broken low start bitrates
due to QCIF being set as default codec in WebRtcVideoEngine2 which caps
the max bitrate to 200kbps.
BUG=1788
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43789004
Cr-Commit-Position: refs/heads/master@{#8780}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8780 4adac7df-926f-26a2-2b94-8c16560cd09d
Original cl description:
This removes the none const pointer entry and SwapFrame.
Since frames delivered using VideoSendStream no longer use the external capture module, VideoSendStream will not get an incoming framerate callback. VideoSendStream now uses a rtc::RateTracker.
Also, the video engine must ensure that time stamps are always increasing.
With this, time stamps (ntp, render_time and rtp timestamps ) are checked and set in ViECapturer::OnIncomingCapturedFrame
This cl was previously reverted in https://webrtc-codereview.appspot.com/46549004/.
Patchset 1 contains the original patch after rebase.
Patshet 2 fix webrtc_perf_tests reported in chromium:465306
Note that chromium:465287 is being fixed in https://webrtc-codereview.appspot.com/43829004/
BUG=1128
R=magjed@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47629004
Cr-Commit-Position: refs/heads/master@{#8776}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8776 4adac7df-926f-26a2-2b94-8c16560cd09d
This flag is passed to existing VieExternalCodec API (and others) to denote encoders that don't require/expect frames from the normal capture pipeline. This is the simplest way to allow camera->encoder texture support, until textures are supported through the normal camera pipeline and the lifetime issues are all figured out (I hear this is on the backlog, but not there yet).
Ideally, the flag would be on the encoder, but that doesn't work with SimulcastEncoderAdapter, since it doesn't create an encoder right away.
Note that this change only affects WebRtcVideoEngine (not WRVE2), since WRVE2 uses video_send_stream, and my hope is that by the time things have switched to WRVE2, textures will be supported with the normal camera pipeline and the dependency on internal sources can be thrown away.
BUG=
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42349004
Cr-Commit-Position: refs/heads/master@{#8769}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8769 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add HUD fragment with HUD related controls and more
HUD statistics.
- Create and set all peer connection constraints in
PeerConnectionClient class.
- Handle registration request in web socket class internally
once web socket connection is opened.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44669004
Cr-Commit-Position: refs/heads/master@{#8762}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8762 4adac7df-926f-26a2-2b94-8c16560cd09d
As of r7849 the built-in AEC on devicing supporting it is enabled by default.
Unfortunately, the SW AEC (AECM) was not disabled, hence running on top of the built-in one. This is not necessary. In fact it reduce double talk performance significantly.
BUG=4431
TESTED=manually
R=henrika@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49419004
Cr-Commit-Position: refs/heads/master@{#8735}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8735 4adac7df-926f-26a2-2b94-8c16560cd09d
Relevant changes:
* src/third_party/android_tools: fd5a8ec..98a4345
Details: 00e438c..8d51d96/DEPS
This required updating our Android projects to API level 22,
as third_party/android_tools dropped support for API level 21.
Command used:
perl -pi -e "s/android-21/android-22/g" `find . -name project.properties`
Using 'android update project' would also work but that changes the
ANDROID_SDK_ROOT -> ANDROID_HOME, which the Chromium build toolchain
doesn't set properly when build/android/envsetup.sh is sourced.
Clang version was not updated in this roll.
R=henrika@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42779004
Cr-Commit-Position: refs/heads/master@{#8728}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8728 4adac7df-926f-26a2-2b94-8c16560cd09d
On fresh checkout AppRTCDemo and corresponding tests
fail to build because resource file R.java is not auto generated properly.
On existing tree R.java will be picked up from previous
build leftover at talk/examples/android/gen.
Build bots did not detect this break for some reason.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43749004
Cr-Commit-Position: refs/heads/master@{#8723}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8723 4adac7df-926f-26a2-2b94-8c16560cd09d
The AppRTCDemoTest is failing if the Android device lacks
an Internet connection (e.g. is in flight mode).
This change makes it benefit from the work done in
https://review.webrtc.org/36769004/ to work around that
limitation for loopback tests.
R=phoglund@webrtc.orgTBR=glaznev@webrtc.org
BUG=4421
TESTED=Successful run on Nexus 7 (2013) in flight mode using:
ninja -C out/Release
. build/android/envsetup.sh
adb install -r out/Release/apks/AppRTCDemo.apk
webrtc/build/android/test_runner.py instrumentation --test-apk AppRTCDemoTest --verbose --release
Review URL: https://webrtc-codereview.appspot.com/45649004
Cr-Commit-Position: refs/heads/master@{#8714}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8714 4adac7df-926f-26a2-2b94-8c16560cd09d
- Updated Java VideoRenderer removes setSize() from video renderer interface.
Remove no longer valid test, which requires setSize() call before any
frame can be rendered.
- test_runner.py tries to run private member of InstrumentationTestCase class.
Workaround it by renaming private loopback test method.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47549004
Cr-Commit-Position: refs/heads/master@{#8707}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8707 4adac7df-926f-26a2-2b94-8c16560cd09d
Also fixed the issue when we have an TransportChannelImpl, the socket
option is not preserved.
Since this is a code path that will be modified by bundle (which Peter also has a test case already), we don't need a test case here.
BUG=4374
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42699004
Cr-Commit-Position: refs/heads/master@{#8702}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8702 4adac7df-926f-26a2-2b94-8c16560cd09d
This cuts down on the amount of string copying we currently do and paves the way for separating the code that fetches the stats from the code that populates the stats reports. As is, that code is intertwined, so we populate the stats on both signaling and worker thread.
I'm also adding some documentation and TODOs for further improvements.
BUG=2822
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47459004
Cr-Commit-Position: refs/heads/master@{#8700}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8700 4adac7df-926f-26a2-2b94-8c16560cd09d
This change is just to allow rolling into Chromium, update Chromium and then commit the actual change in WebRTC that requires the interface change. It allows using a StatsReport::Id object as a pointer (foo->Bar()), since in an upcoming change, Id objects will be pointers.
R=magjed@webrtc.org
BUG=2822
Review URL: https://webrtc-codereview.appspot.com/43689004
Cr-Commit-Position: refs/heads/master@{#8697}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8697 4adac7df-926f-26a2-2b94-8c16560cd09d
This reverts r8683 and is a reland of r8682.
Reason for revert: The thread checker in Chromium that crashed has been fixed now.
BUG=1128
TBR=tommi,pbos,pthatcher
Review URL: https://webrtc-codereview.appspot.com/40319004
Cr-Commit-Position: refs/heads/master@{#8696}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8696 4adac7df-926f-26a2-2b94-8c16560cd09d
