This is in preparation for
https://webrtc-review.googlesource.com/c/src/+/36340
With these changes we can avoid some strange #ifdefs in the code
that uses temporal layers.
Bug: webrtc:7925
Change-Id: I472210738ccc9f73812b8863951befeabec56f15
Reviewed-on: https://webrtc-review.googlesource.com/41280
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Anders Carlsson <andersc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21759}
Try to use frame timestamps first if they look reasonable, otherwise
use realtime clock.
Also, lower limit from 90% of target to 85%.
Bug: webrtc:4172, chromium:802290
Change-Id: Iad489be7c7cf637345be4795e5089936ab9fab07
Reviewed-on: https://webrtc-review.googlesource.com/41041
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21729}
This is a reland of https://webrtc-review.googlesource.com/34380
The main problem with that CL was that we used frame timestamps as basis
for frame dropping, but those might not be continuous or even populated
in some circumstances.
Additionally, I found that the bitrate was off since the encoder does
not not take the dropped frames into account, so if we drop every other
frame continiusoly, the bitrate sent will be around half of the target.
Patch set 1 is the original CL, subsequent patch sets cotains fixes.
Bug: webrtc:4172
Change-Id: I8ec8dddcebf4ce44f28dd9055cf9c46bbd68e4a6
Reviewed-on: https://webrtc-review.googlesource.com/39201
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21601}
This reverts commit 28a06b16cc.
Reason for revert: Causes some unexpected perf changes.
Original change's description:
> Smoother frame dropping when screenshare_layers limits fps
>
> Currently, when input fps is higher than the configured target fps in
> screenshare_layers, we drop frames with the help of a rate tracker using
> a one second sliding window. This is not optimal.
> For instance, given a 5fps limit and a 30fps capturer, the window will
> not be saturated until we have added the first 5 frames. Then we will
> drop all frames until the oldest one drops out, at which point we can
> immediately fill it's place. This results in quick 5 frame bursts every
> second.
>
> In addition to rate tracker, also set a limit on minimum interval
> required between input frames, based on target frame rate.
>
> Bug: webrtc:4172
> Change-Id: I49f0abf4d549673cc6b3fafe580b529ea3feaf57
> Reviewed-on: https://webrtc-review.googlesource.com/34380
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#21325}
TBR=ilnik@webrtc.org,sprang@webrtc.org
Change-Id: I7ca5b0c847310dbb11dce28773082eac946c0ba4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:4172
Reviewed-on: https://webrtc-review.googlesource.com/34780
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21354}
Currently, when input fps is higher than the configured target fps in
screenshare_layers, we drop frames with the help of a rate tracker using
a one second sliding window. This is not optimal.
For instance, given a 5fps limit and a 30fps capturer, the window will
not be saturated until we have added the first 5 frames. Then we will
drop all frames until the oldest one drops out, at which point we can
immediately fill it's place. This results in quick 5 frame bursts every
second.
In addition to rate tracker, also set a limit on minimum interval
required between input frames, based on target frame rate.
Bug: webrtc:4172
Change-Id: I49f0abf4d549673cc6b3fafe580b529ea3feaf57
Reviewed-on: https://webrtc-review.googlesource.com/34380
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21325}
This is expected to result in a slight loss of overall quality, but
should offset by quicker switching between temporal layers with flaky
connections.
Bug: webrtc:7694
Change-Id: Ib605802bb59f12773652324ac66cdf4774ae6bb6
Reviewed-on: https://webrtc-review.googlesource.com/6881
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20160}
All frames are checked against hard-coded dependency graph
using new helper class. It's invoked in RTC_DCHECK(). Only
DefaultTemporalLayers are fully implemented in this CL, checker
for ScreenshareLayers is not doing anything for now.
Bug: none
Change-Id: I3ec017176d8c25f7572c8f161e52f2ebfac8220f
Reviewed-on: https://webrtc-review.googlesource.com/3740
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20066}
In https://webrtc-review.googlesource.com/c/src/+/1560 we moved WebRTC
from src/webrtc to src/ (in order to preserve an healthy git history).
This CL takes care of fixing header guards, #include paths, etc...
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=tommi@webrtc.org
Bug: chromium:611808
Change-Id: Iea91618212bee0af16aa3f05071eab8f93706578
Reviewed-on: https://webrtc-review.googlesource.com/1561
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19846}
In order to eliminate the WebRTC Subtree mirror in Chromium,
WebRTC is moving the content of the src/webrtc directory up
to the src/ directory.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=tommi@webrtc.org
Bug: chromium:611808
Change-Id: Iac59c5b51b950f174119565bac87955a7994bc38
Reviewed-on: https://webrtc-review.googlesource.com/1560
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19845}
2017-09-15 04:25:06 +00:00
Renamed from webrtc/modules/video_coding/codecs/vp8/screenshare_layers.cc (Browse further)
