- "WebRTC.Video.QualityLimitedResolutionInPercent"
and if a frame is downscaled, the average number of times the frame is downscaled:
- "WebRTC.Video.QualityLimitedResolutionDownscales"
BUG=
Review URL: https://codereview.webrtc.org/1325153009
Cr-Commit-Position: refs/heads/master@{#10319}
Implements SupportsNativeHandle() in SimulcastEncoderAdapter which works
when there's only a single encoder.
BUG=webrtc:5060
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1397653004
Cr-Commit-Position: refs/heads/master@{#10291}
Since padding is no longer sent on Encoded() callbacks, dummy callbacks
aren't required to generate padding. This skip-frame behavior can then
be removed to get rid of dummy callbacks though nothing was encoded. As
frames don't have to be generated for frames that don't have to be sent
we skip encoding frames that aren't intended to be sent either, reducing
CPU load.
BUG=
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1369923005 .
Cr-Commit-Position: refs/heads/master@{#10181}
This CL changes the threshold where we consider a block to be static and
of sufficient quality to not spend bits/CPU encoding it.
Perf note: This change may result in a minor degradation of PSNR/SSIM
and available send bitrate. CPU usage and bitrate sent should however
be greately reduced.
BUG=webrtc:5015
Review URL: https://codereview.webrtc.org/1383533002
Cr-Commit-Position: refs/heads/master@{#10134}
Our perf test suite webrtc_perf_tests timed out, which caused most
of the delay landing this (https://crbug.comn/535973 and
https://codereview.chromium.org/1370133004).
Other problems with executing Android tests also needed to be
resolved in order to land this (http://crbug.com/534849).
Libvpx has moved from third_party/libvpx to third_party/libvpx_new
as of https://codereview.chromium.org/1323333002/
Android GN was blocking this roll due to a problem that ended up
being caused by a bug (http://crbug.com/534849).
Relevant changes:
* src/buildtools: f7310ee..8d89c1b
* src/third_party/boringssl/src: 1d128f3..4c60d35
* src/third_party/icu: 6b3ce81..423fc7e
* src/third_party/libjpeg_turbo: 631e2dd..e4e7503
* src/third_party/libvpx: ac1772e..70db223
* src/third_party/libyuv: fcacbfb..62c49dc
* src/tools/gyp: 5d01a8c..01528c7
* src/tools/swarming_client: 77f720b..6e5d2b2
Details: 310ea93..8cf53d6/DEPS
Clang version changed 245965:247874
Details: 310ea93..8cf53d6/tools/clang/scripts/update.sh
BUG=481034, 535973
TBR=marpan@webrtc.org
Review URL: https://codereview.webrtc.org/1355083002
Cr-Commit-Position: refs/heads/master@{#10101}
Android hardware H.264 seems to keep a steady high-QP flow instead of
dropping frames, so framedrops aren't sufficient to detect a bad state
where downscaling would be beneficial.
BUG=webrtc:4968
R=magjed@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1364253002 .
Cr-Commit-Position: refs/heads/master@{#10078}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
This change includes several improvements:
* VP8 configured with new rate control
* Detection of frame dropping, with qp bump for next frame
* Increased target and TL0 bitrates
* Reworked rate control (TL allocation) in screenshare_layers
A note on performance: PSNR and SSIM is expected to get slightly worse with this cl. Frame drops and delays should however improve.
BUG=4171
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1193513006.
Cr-Commit-Position: refs/heads/master@{#9495}
It is just a pass through to webrtc/video_frame.h. Updated the callers
to include webrtc/video_frame.h instead and removed i420_video_frame.h.
This should fix pbos' TODO in i420_video_frame.h.
Tested on Linux with the following command lines:
$ rm -rf out/
$ ./webrtc/build/gyp_webrtc
$ ninja -C out/Debug
BUG=None
TEST=see above
R=magjed@webrtc.org, pbos@webrtc.org, tommi@webrtc.orgTBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46819004
Patch from Thiago Farina <tfarina@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#8973}
We should not continue the program if the user asked for help.
Tested on Linux with the following command line:
$ out/Debug/frame_analyzer --help
BUG=None
TEST=see above
R=kjellander@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44069004
Patch from Thiago Farina <tfarina@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#8961}
Now when we don't use SwapFrame consistently anymore, we need to recycle allocations with a buffer pool instead. This CL adds a buffer pool class, and updates the vp8 decoder to use it. If this CL lands successfully I will update the other video producers as well.
BUG=1128
R=stefan@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41189004
Cr-Commit-Position: refs/heads/master@{#8748}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8748 4adac7df-926f-26a2-2b94-8c16560cd09d
Allow for setting different cpu_speed setting based on resolution, for non-simulcast.
Use the existing low resolution simulcast cpu_speed setting for the non-simulcast case.
No change to simulcast behavior, unless top/highest layer stream is also below CIF resolution,
(in which case all layers will use lower the cpu_speed setting =-4).
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37319004
Cr-Commit-Position: refs/heads/master@{#8603}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8603 4adac7df-926f-26a2-2b94-8c16560cd09d
Clang version changed 223108:230914
Details: e144d30..6fdb142/tools/clang/scripts/update.sh
Removes the OVERRIDE macro defined in:
* webrtc/base/common.h
* webrtc/typedefs.h
The majority of the source changes were done by running this in src/:
perl -0pi -e "s/virtual\s([^({;]*(\([^({;]*\)[^({;]*))(OVERRIDE|override)/\1override/sg" `find {talk,webrtc} -name "*.h" -o -name "*.cc*" -o -name "*.mm*"`
which converted all:
virtual Foo() OVERRIDE
functions to:
Foo() override
Then I manually edited:
* talk/media/webrtc/fakewebrtccommon.h
* webrtc/test/fake_common.h
Remaining uses of OVERRIDE was fixed by search+replace.
Manual edits were done to fix virtual destructors that were
overriding inherited ones.
Finally a build error related to the pure virtual definitions of
Read, Write and Rewind in common_types.h required a bit of
refactoring in:
* webrtc/common_types.cc
* webrtc/common_types.h
* webrtc/system_wrappers/interface/file_wrapper.h
* webrtc/system_wrappers/source/file_impl.cc
This roll should make it possible for us to finally re-enable deadlock
detection for TSan on the buildbots.
BUG=4106
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41069004
Cr-Commit-Position: refs/heads/master@{#8596}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8596 4adac7df-926f-26a2-2b94-8c16560cd09d
Mostly, it's about moving constructors and descructors to the .cc
files, so that they won't be inlined everywhere.
The reason this CL is so big is that a lot of code was using
common_types.h without declaring a dependency on webrtc_common, which
broke the build once common_types.h started to depend on
common_types.cc.
BUG=163
R=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26089004
Cr-Commit-Position: refs/heads/master@{#8516}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8516 4adac7df-926f-26a2-2b94-8c16560cd09d
Modifies WebRtcVideoSendStream to use a default width/height of 16px.
This significantly reduces SetRemoteDescription time under
WebRtcVideoEngine2. Also preventing (expensive) reconfigurations due to
incoming frames when the channel is not sending yet.
Tests have been modified to generate a frame before expecting a certain
encoder size to have been configured.
Also adding tracing to WebRtcVideoSendStream::InputFrame as it can lead
to reconfigurations of the encoder which is expensive and it should show
up in chrome://tracing.
BUG=1788
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42369004
Cr-Commit-Position: refs/heads/master@{#8381}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8381 4adac7df-926f-26a2-2b94-8c16560cd09d
