I've kicked of a roll into Chromium with out the WebRtcVideoEngine2 change, to see if it was causing the roll problems, but re-landing in the meantime.
> Revert 8809 "Set WebRtcVideoEngine2 as the WebRtcMediaEngine."
> content_browsertests started failing around the time the change landed and rolls are failing now.
> I'm going to try rolling this back, start a roll, and then re-land.
>
> > Set WebRtcVideoEngine2 as the WebRtcMediaEngine.
> >
> > Removes the experiment launching WebRTC-NewVideoAPI. This field trial
> > has shown no major regressions on Chrome Canary/Dev that haven't been
> > addressed, so enabling it in time before feature freeze.
> >
> > BUG=1788
> > R=mflodman@webrtc.org
> >
> > Review URL: https://webrtc-codereview.appspot.com/44759004
>
> TBR=pbos@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/43889004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50459004
Cr-Commit-Position: refs/heads/master@{#8817}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8817 4adac7df-926f-26a2-2b94-8c16560cd09d
content_browsertests started failing around the time the change landed and rolls are failing now.
I'm going to try rolling this back, start a roll, and then re-land.
> Set WebRtcVideoEngine2 as the WebRtcMediaEngine.
>
> Removes the experiment launching WebRTC-NewVideoAPI. This field trial
> has shown no major regressions on Chrome Canary/Dev that haven't been
> addressed, so enabling it in time before feature freeze.
>
> BUG=1788
> R=mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/44759004TBR=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43889004
Cr-Commit-Position: refs/heads/master@{#8816}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8816 4adac7df-926f-26a2-2b94-8c16560cd09d
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
