Modify bitrate controller to update bitrate based on process call and not
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5794 4adac7df-926f-26a2-2b94-8c16560cd09d
This triggered an occasional TSAN failure in
CallTest.ReceivesPliAndRecoversWithNack e.g.:
http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1444/steps/memory%20test%3A%20video_engine_tests/logs/stdio
I managed to reproduce this locally and verified that reverting this CL
corrected it.
> Modify bitrate controller to update bitrate based on process call and not
> only whenever a RTCP receiver block is received.
>
> Additionally:
> Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
>
> Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
>
> Did not touch decrease logic, however since it can be triggered more often it
> may decrease much faster and closer to the original written cap of once every
> 300ms + rtt.
>
> Note:
> rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
> bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
>
> BUG=3065
> R=stefan@webrtc.org, mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/10529004TBR=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10079005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5785 4adac7df-926f-26a2-2b94-8c16560cd09d
only whenever a RTCP receiver block is received.
Additionally:
Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.
Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).
Did not touch decrease logic, however since it can be triggered more often it
may decrease much faster and closer to the original written cap of once every
300ms + rtt.
Note:
rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.
BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5775 4adac7df-926f-26a2-2b94-8c16560cd09d
Camera start is a blocking operation so never a good idea to do on a main
thread, but worse than that is that the guts of WebView appear to be
interacting with capture start in a bad way causing startup to pause for 10s
while a timeout expires. This change eliminates that 10s delay.
R=noahric@google.com
Review URL: https://webrtc-codereview.appspot.com/10449004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5772 4adac7df-926f-26a2-2b94-8c16560cd09d
These changes are currently not used in webrtc/ but helps in using the delay estimator.
* The last_delay_quality() is updated with respect to robust_validation and changed to return float.
* Tests are updated wtih respect to above.
* Adds the possibility to make a soft reset based on external circumstances like a known delay shift has been made.
* The soft reset change the lookahead dynamically. An API to ask for current lookahead has been added as well.
BUG=N/A
TESTED=trybots, modules_unittest
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10409004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5761 4adac7df-926f-26a2-2b94-8c16560cd09d
To be used by a codec implementation. Could for instance be interpreted
as trying to fit as much as possible on one temporal layer and send
everything that doesn't fit within target bitrate on another one.
Prevents an existing hack where startBitrate is used by a codec
implementation to signify target bitrate. This hack forces a reset of
bitrate estimation to target bitrate which creates bitrate dips.
BUG=
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10479004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5759 4adac7df-926f-26a2-2b94-8c16560cd09d
- Move condition of 0 bps as max meaning 1gbps from SendSideBandwidthEstimation to BitrateController.
- Remove condition on bitrate=0 meaning bandwidth estimation off as that could only happen when no observers existed
and in which case the estimation would be ignored.
- Add MaybeTriggerOnNetworkChanged which only runs rate allocation if any of the dependent variables has changed
thus allowing to remove many of the bool returns that try to indicate if the estimation has changed which would not
be aware if the observers have changed.
- SendSideBandwidthEstimation now has a UpdateBitrate and has clear code paths to which calls update bitrate.
- Changes in enforce_min_bitrate so the 10kbps min is set from the BitrateController and not from the outside this keep valid as observers are changed.
R=henrik.lundin@webrtc.org, stefan@webrtc.org
BUG=3065
Review URL: https://webrtc-codereview.appspot.com/10189004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5752 4adac7df-926f-26a2-2b94-8c16560cd09d
In the case where a network glitch causes a packet to arrive so late
that the jitter buffer has gone into expand mode, the playout timestamp
could have been increased to a value that is larger than the RTP
timestamp of the late packet when it finally arrives. This causes
the difference to be negative, and would make the value wrap (unsigned).
With this fix, the difference is set to zero when the playout
timestamp is ahead of the incoming RTP timestamp. Further down in the
method, a zero-value will lead to the averaging filter not being updated.
BUG=3080
R=henrika@webrtc.org, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10199004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5735 4adac7df-926f-26a2-2b94-8c16560cd09d
GetWindowRect includes the window frames for maximized window even they are off screen, causing content outside the window being captured falsely. The fix is to remove the left/right/bottom window frame from the captured rect. Mouse capturing is adjusted accordingly as well.
BUG=3076
R=sergeyu@chromium.org
Review URL: https://webrtc-codereview.appspot.com/10149004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5732 4adac7df-926f-26a2-2b94-8c16560cd09d
- An RTX packet with no payload should be dropped prior to parsing RTX header since it doesn't have an RTX header. This can for example happen when sending padding-only packets over the RTX stream.
- The retransmit code path when the pacer is disabled doesn't properly update the abs-send-time and ts-offset header extensions.
TEST=trybots
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/9189004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5728 4adac7df-926f-26a2-2b94-8c16560cd09d
Disabling as bots are turning red. This should be because
VideoSendStream::ReconfigureVideoCodec caps video_codec.startBitrate to
max bitrates and as the start bitrate is just enough to transmit there
might be some rounding errors here causing the top stream not to be
sent. Since no REMB is received (send-side test) this remains as the
transmit bitrate.
I need some more time to figure out if this is the case so I'm disabling
these for now to avoid reverting the big CL. VideoSendStreams aren't
used in production yet.
TBR=mflodman@webrtc.org
BUG=3078
Review URL: https://webrtc-codereview.appspot.com/10229005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5727 4adac7df-926f-26a2-2b94-8c16560cd09d
New interface uses two bitrates (max/min). The pace multiplier is also
removed from the interface and instead utilized outside. Min bitrate
will be filled with padding if there's not enough media to transmit.
Also fixes a bug in minimum transmission bitrate that made it ignore
REMBs. A regression test has been added to catch it.
BUG=3014
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10059004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5723 4adac7df-926f-26a2-2b94-8c16560cd09d
Replaces VideoCodec in VideoSendStream::Config with an EncoderSettings
struct. The EncoderSettings struct uses an external encoder for all
codecs. This means that external users, such as libjingle, will provide
the encoders themselves, removing the previous distinction of internal
and external codecs.
For now VideoSendStream translates to VideoCodec internally. In the
interrim (before the corresponding change is implemented in
VideoReceiveStream) tests convert EncoderSettings to VideoCodecs.
Removes Call::GetVideoCodecs().
Disables RampUpTest.WithPacingAndRtx as its further exposed with changes
to bitrates used in tests.
BUG=2854,2992
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/7919004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5722 4adac7df-926f-26a2-2b94-8c16560cd09d
The deadlock can happen when using HW encoder. HW encoder calls
the encode complete callback on libjingle worker thread instead
of ViECaptureThread. The capture thread can hold VieEncoder::|data_cs_|
and wait for ModuleRtpRtcpImpl::|critical_section_module_ptrs_|.
When libjingle worker thread runs encode complete callback, it
can hold ModuleRtpRtcpImpl::|critical_section_module_ptrs_| and
wait for VieEncoder::|data_cs_|.
|default_rtp_rtcp_| is not guarded by |data_cs|. So move it out of
the critical section to avoid the deadlock.
BUG=chromium:352567
TEST=Run apprtc loopback on CrOS.
Run apprtc between CrOS and Linux.
Run vie_auto_test.
R=henrik.lundin@webrtc.org, pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10039004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5721 4adac7df-926f-26a2-2b94-8c16560cd09d
