Issue https://webrtc-codereview.appspot.com/4459004/ was commited as
r5259, after which flakiness was detected and a rollback was performed
at r5261.
Patch Set 1 of this issue is the code submitted in r5259. Subsequent
patch sets fixes a race condition which caused the seen problems.
The root cause was a dead lock between a thread sending rtp packets and
and a timed module processing thread:
webrtc::RTPSender::BitrateUpdated() // Get RTPSender stats lock
webrtc::Bitrate::Process() // Get Bitrate lock
webrtc::RTPSender::ProcessBitrate()
webrtc::ModuleRtpRtcpImpl::Process()
...
webrtc::Bitrate::Update() // Get Bitrate lock
webrtc::RTPSender::UpdateRtpStats() // Get RTPSender stats lock
webrtc::RTPSender::SendToNetwork()
...
This is fixed in Bitrate::Process() by releasing the lock before
calling the callback.
BUG=2235
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/5619004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5281 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL makes the padding packets get their own RTP timestamps,
rather than having the same timestamp as the last sent video
packet. The purpose is to solve Issue 2611, where the overuse-
detector does not react to padding packets.
A test was implemented to verify that the padding packets do
get their own timestamps.
BUG=2611
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/3869004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5125 4adac7df-926f-26a2-2b94-8c16560cd09d
- A bug was introduced in r4234 causing no paced packets to be sent.
- Only update the sequence number counter if a padding packet is actually going to be sent, to avoid packet loss.
- Have all packets go through the pacer if pacing is enabled to avoid reordering.
- Fix race condition on reading capture_time_ms_/timestamp_ in rtp_sender.cc.
BUG=1837
TEST=trybots and vie_auto_test --automated
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1682004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4246 4adac7df-926f-26a2-2b94-8c16560cd09d
This connects the pacer-based padding with the RTP modules, which will
generate padding packets roughly according to what the pacer suggests.
It will only generate padding packets of maximum size to keep the number
off padding packets as small as possible. This also sets a limit of how much
padding + media bitrate which the pacer is allowed to "request" from the
RTP modules.
Padding will for now only be generated by the first sending RTP module.
BUG=1837
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1612005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4234 4adac7df-926f-26a2-2b94-8c16560cd09d
The goal with this new clock interface is to have something which is used all
over WebRTC to make it easier to switch clock implementation depending on where
the components are used. This is a first step in that direction.
Next steps will be to, step by step, move all modules, video engine and voice
engine over to the new interface, effectively deprecating the old clock
interfaces. Long-term my vision is that we should be able to deprecate the clock
of WebRTC and rely on the user providing the implementation.
TEST=vie_auto_test, rtp_rtcp_unittests, trybots
Review URL: https://webrtc-codereview.appspot.com/1041004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3381 4adac7df-926f-26a2-2b94-8c16560cd09d
