Adding a receive side API for buffering mode.
At the same time, renaming the send side API.
Review URL: https://webrtc-codereview.appspot.com/1104004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3525 4adac7df-926f-26a2-2b94-8c16560cd09d
diff --git a/webrtc/modules/video_coding/main/source/timing.cc b/webrtc/modules/video_coding/main/source/timing.cc
index 36131b1..26bda7e 100644
--- a/webrtc/modules/video_coding/main/source/timing.cc
+++ b/webrtc/modules/video_coding/main/source/timing.cc
@@ -34,7 +34,8 @@
_minTotalDelayMs(0),
_requiredDelayMs(0),
_currentDelayMs(0),
-_prevFrameTimestamp(0)
+_prevFrameTimestamp(0),
+_maxVideoDelayMs(kMaxVideoDelayMs)
{
if (masterTiming == NULL)
{
@@ -131,7 +132,7 @@
WebRtc_Word64 delayDiffMs = static_cast<WebRtc_Word64>(targetDelayMs) -
_currentDelayMs;
// Never change the delay with more than 100 ms every second. If we're changing the
- // delay in too large steps we will get noticable freezes. By limiting the change we
+ // delay in too large steps we will get noticeable freezes. By limiting the change we
// can increase the delay in smaller steps, which will be experienced as the video is
// played in slow motion. When lowering the delay the video will be played at a faster
// pace.
@@ -249,7 +250,7 @@
{
WebRtc_Word64 estimatedCompleteTimeMs =
_tsExtrapolator->ExtrapolateLocalTime(frameTimestamp);
- if (estimatedCompleteTimeMs - nowMs > kMaxVideoDelayMs)
+ if (estimatedCompleteTimeMs - nowMs > _maxVideoDelayMs)
{
if (_master)
{
@@ -323,6 +324,12 @@
return static_cast<WebRtc_Word32>(availableProcessingTimeMs) - maxDecodeTimeMs > 0;
}
+void VCMTiming::SetMaxVideoDelay(int maxVideoDelayMs)
+{
+ CriticalSectionScoped cs(_critSect);
+ _maxVideoDelayMs = maxVideoDelayMs;
+}
+
WebRtc_UWord32
VCMTiming::TargetVideoDelay() const
{