A new RtpRtcpClock interface has been added to rtp_rtcp_defines.h
and provides time facilities used by an RTP/RTCP module. Also,
NTP constants have been made public in the
webrtc::ModuleRTPUtility namespace to make implementation of
external clocks easier.
An overloaded version of CreateRtpRtcp() accepts a clock argument. By
default, if no clock is provided, the module uses the system clock
(old ModuleRTPUtility implementation).
Throughout the RTP/RTCP module code, calls to TickTime and
ModuleRTPUtility time functions have been replaced with calls to time
methods on a clock object.
The following classes take a clock object in their constructor and
hold a _clock field (either directly, or inherited from a parent):
Bitrate
ModuleRtpRtcpImpl
RTCPReceiver
RTCPSender
RTPReceiver
RTPSender
RTPSenderAudio
RTPSenderVideo
Methods from other classes that do not derive any of those and
require a time take an additional nowMS parameter, that should be
the result of calling GetTimeInMS() on a clock object.
Review URL: http://webrtc-codereview.appspot.com/268017
git-svn-id: http://webrtc.googlecode.com/svn/trunk@1076 4adac7df-926f-26a2-2b94-8c16560cd09d
Changing how the max payload length is calculated. Instead
of handling RTP and FEC header overhead explicitly, call the
MaxDataPayloadLength method which already does it. Avoid redundant code. Had to move MaxDataPayloadLength to the
RTPSenderInterface.
Review URL: http://webrtc-codereview.appspot.com/269002
git-svn-id: http://webrtc.googlecode.com/svn/trunk@901 4adac7df-926f-26a2-2b94-8c16560cd09d
Issues solved:
1. Possible overflow when reducing the bandwidth estimate at the send-side
2. A burst of loss reports could make us reduce the rate way too far since
we reduced the rate relative the current estimate and not the actual
rate sent.
BUG=
TEST=
Review URL: http://webrtc-codereview.appspot.com/244011
git-svn-id: http://webrtc.googlecode.com/svn/trunk@822 4adac7df-926f-26a2-2b94-8c16560cd09d
