- 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
The CL was reverted in r5712, due to bots going red. However, these bots
are unrelated to this CL.
Original description:
VideoSendStreamTest.SuspendBelowMinBitrate was flaky. The problem was
that when the first non-padding packet was sent after the stream was
resumed, the statistics had not always been updated so that
stats.suspended was false. After seeing the first non-padding packet
after suspension, the test will now go into a state where it waits for
the statistics to be changed.
BUG=3068
R=pbos@webrtc.orgTBR=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10099004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5713 4adac7df-926f-26a2-2b94-8c16560cd09d
VideoSendStreamTest.SuspendBelowMinBitrate was flaky. The problem was that when the first non-padding packet was sent after the stream was resumed, the statistics had not always been updated so that stats.suspended was false. After seeing the first non-padding packet after suspension, the test will now go into a state where it waits for the statistics to be changed.
BUG=3068
R=pbos@webrtc.orgTBR=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/10069004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5711 4adac7df-926f-26a2-2b94-8c16560cd09d
