admin/webrtc_m130
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
webrtc_m130/modules/rtp_rtcp/source/playout_delay_oracle.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

67 lines
2.3 KiB
C++
Raw Normal View History

Add sender controlled playout delay limits This CL adds support for an extension on RTP frames to allow the sender to specify the minimum and maximum playout delay limits. The receiver makes a best-effort attempt to keep the capture-to-render delay within this range. This allows different types of application to specify different end-to-end delay goals. For example gaming can support rendering of frames as soon as received on receiver to minimize delay. A movie playback application can specify a minimum playout delay to allow fixed buffering in presence of network jitter. There are no tests at this time and most of testing is done with chromium webrtc prototype. On chromoting performance tests, this extension helps bring down end-to-end delay by about 150 ms on small frames. BUG=webrtc:5895 Review-Url: https://codereview.webrtc.org/2007743003 Cr-Commit-Position: refs/heads/master@{#13059}
2016-06-08 00:24:21 -07:00
/*
* Copyright (c) 2016 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#include "webrtc/modules/rtp_rtcp/source/playout_delay_oracle.h"
#include "webrtc/modules/rtp_rtcp/include/rtp_rtcp_defines.h"
Move implmentation specific constants out of rtp_header_extension.h BUG=None Review-Url: https://codereview.webrtc.org/2642783006 Cr-Commit-Position: refs/heads/master@{#16222}
2017-01-23 11:10:20 -08:00
#include "webrtc/modules/rtp_rtcp/source/rtp_header_extensions.h"
Rename webrtc/base -> webrtc/rtc_base NOPRESUBMIT=True # cpplint errors that aren't caused by this CL. NOTRY=True NOTREECHECKS=True TBR=kwiberg@webrtc.org, kjellander@webrtc.org Bug: webrtc:7634 Change-Id: I3cca0fbaa807b563c95979cccd6d1bec32055f36 Reviewed-on: https://chromium-review.googlesource.com/562156 Commit-Queue: Edward Lemur <ehmaldonado@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#18919}
2017-07-06 19:44:34 +02:00
#include "webrtc/rtc_base/checks.h"
#include "webrtc/rtc_base/logging.h"
Add sender controlled playout delay limits This CL adds support for an extension on RTP frames to allow the sender to specify the minimum and maximum playout delay limits. The receiver makes a best-effort attempt to keep the capture-to-render delay within this range. This allows different types of application to specify different end-to-end delay goals. For example gaming can support rendering of frames as soon as received on receiver to minimize delay. A movie playback application can specify a minimum playout delay to allow fixed buffering in presence of network jitter. There are no tests at this time and most of testing is done with chromium webrtc prototype. On chromoting performance tests, this extension helps bring down end-to-end delay by about 150 ms on small frames. BUG=webrtc:5895 Review-Url: https://codereview.webrtc.org/2007743003 Cr-Commit-Position: refs/heads/master@{#13059}
2016-06-08 00:24:21 -07:00
namespace webrtc {
PlayoutDelayOracle::PlayoutDelayOracle()
: high_sequence_number_(0),
send_playout_delay_(false),
ssrc_(0),
Merge min_ms and max_ms accessors in PlayoutDelayOracle to reduce CriticalSection enterencies and avoid potentional synchronisation issues. R=isheriff@chromium.org Review URL: https://codereview.webrtc.org/2312143002 . Cr-Commit-Position: refs/heads/master@{#14101}
2016-09-07 13:29:47 +02:00
playout_delay_{-1, -1} {}
Remove thread_checker in playout_delay_oracle It appears there the encode and send operation can happen over multiple threads. Also, padding data itself may be sent on a different thread. Remove thread checker and protect all data with crit_sect. BUG=webrtc:5998 TBR=stefan@webrtc.org Review-Url: https://codereview.webrtc.org/2066863002 Cr-Commit-Position: refs/heads/master@{#13137}
2016-06-14 10:55:36 -07:00
Add sender controlled playout delay limits This CL adds support for an extension on RTP frames to allow the sender to specify the minimum and maximum playout delay limits. The receiver makes a best-effort attempt to keep the capture-to-render delay within this range. This allows different types of application to specify different end-to-end delay goals. For example gaming can support rendering of frames as soon as received on receiver to minimize delay. A movie playback application can specify a minimum playout delay to allow fixed buffering in presence of network jitter. There are no tests at this time and most of testing is done with chromium webrtc prototype. On chromoting performance tests, this extension helps bring down end-to-end delay by about 150 ms on small frames. BUG=webrtc:5895 Review-Url: https://codereview.webrtc.org/2007743003 Cr-Commit-Position: refs/heads/master@{#13059}
2016-06-08 00:24:21 -07:00
PlayoutDelayOracle::~PlayoutDelayOracle() {}
void PlayoutDelayOracle::UpdateRequest(uint32_t ssrc,
PlayoutDelay playout_delay,
uint16_t seq_num) {
rtc::CritScope lock(&crit_sect_);
Move implmentation specific constants out of rtp_header_extension.h BUG=None Review-Url: https://codereview.webrtc.org/2642783006 Cr-Commit-Position: refs/heads/master@{#16222}
2017-01-23 11:10:20 -08:00
RTC_DCHECK_LE(playout_delay.min_ms, PlayoutDelayLimits::kMaxMs);
RTC_DCHECK_LE(playout_delay.max_ms, PlayoutDelayLimits::kMaxMs);
Add sender controlled playout delay limits This CL adds support for an extension on RTP frames to allow the sender to specify the minimum and maximum playout delay limits. The receiver makes a best-effort attempt to keep the capture-to-render delay within this range. This allows different types of application to specify different end-to-end delay goals. For example gaming can support rendering of frames as soon as received on receiver to minimize delay. A movie playback application can specify a minimum playout delay to allow fixed buffering in presence of network jitter. There are no tests at this time and most of testing is done with chromium webrtc prototype. On chromoting performance tests, this extension helps bring down end-to-end delay by about 150 ms on small frames. BUG=webrtc:5895 Review-Url: https://codereview.webrtc.org/2007743003 Cr-Commit-Position: refs/heads/master@{#13059}
2016-06-08 00:24:21 -07:00
RTC_DCHECK_LE(playout_delay.min_ms, playout_delay.max_ms);
int64_t unwrapped_seq_num = unwrapper_.Unwrap(seq_num);
if (playout_delay.min_ms >= 0 &&
Merge min_ms and max_ms accessors in PlayoutDelayOracle to reduce CriticalSection enterencies and avoid potentional synchronisation issues. R=isheriff@chromium.org Review URL: https://codereview.webrtc.org/2312143002 . Cr-Commit-Position: refs/heads/master@{#14101}
2016-09-07 13:29:47 +02:00
playout_delay.min_ms != playout_delay_.min_ms) {
Add sender controlled playout delay limits This CL adds support for an extension on RTP frames to allow the sender to specify the minimum and maximum playout delay limits. The receiver makes a best-effort attempt to keep the capture-to-render delay within this range. This allows different types of application to specify different end-to-end delay goals. For example gaming can support rendering of frames as soon as received on receiver to minimize delay. A movie playback application can specify a minimum playout delay to allow fixed buffering in presence of network jitter. There are no tests at this time and most of testing is done with chromium webrtc prototype. On chromoting performance tests, this extension helps bring down end-to-end delay by about 150 ms on small frames. BUG=webrtc:5895 Review-Url: https://codereview.webrtc.org/2007743003 Cr-Commit-Position: refs/heads/master@{#13059}
2016-06-08 00:24:21 -07:00
send_playout_delay_ = true;
Merge min_ms and max_ms accessors in PlayoutDelayOracle to reduce CriticalSection enterencies and avoid potentional synchronisation issues. R=isheriff@chromium.org Review URL: https://codereview.webrtc.org/2312143002 . Cr-Commit-Position: refs/heads/master@{#14101}
2016-09-07 13:29:47 +02:00
playout_delay_.min_ms = playout_delay.min_ms;
Add sender controlled playout delay limits This CL adds support for an extension on RTP frames to allow the sender to specify the minimum and maximum playout delay limits. The receiver makes a best-effort attempt to keep the capture-to-render delay within this range. This allows different types of application to specify different end-to-end delay goals. For example gaming can support rendering of frames as soon as received on receiver to minimize delay. A movie playback application can specify a minimum playout delay to allow fixed buffering in presence of network jitter. There are no tests at this time and most of testing is done with chromium webrtc prototype. On chromoting performance tests, this extension helps bring down end-to-end delay by about 150 ms on small frames. BUG=webrtc:5895 Review-Url: https://codereview.webrtc.org/2007743003 Cr-Commit-Position: refs/heads/master@{#13059}
2016-06-08 00:24:21 -07:00
high_sequence_number_ = unwrapped_seq_num;
}
if (playout_delay.max_ms >= 0 &&
Merge min_ms and max_ms accessors in PlayoutDelayOracle to reduce CriticalSection enterencies and avoid potentional synchronisation issues. R=isheriff@chromium.org Review URL: https://codereview.webrtc.org/2312143002 . Cr-Commit-Position: refs/heads/master@{#14101}
2016-09-07 13:29:47 +02:00
playout_delay.max_ms != playout_delay_.max_ms) {
Add sender controlled playout delay limits This CL adds support for an extension on RTP frames to allow the sender to specify the minimum and maximum playout delay limits. The receiver makes a best-effort attempt to keep the capture-to-render delay within this range. This allows different types of application to specify different end-to-end delay goals. For example gaming can support rendering of frames as soon as received on receiver to minimize delay. A movie playback application can specify a minimum playout delay to allow fixed buffering in presence of network jitter. There are no tests at this time and most of testing is done with chromium webrtc prototype. On chromoting performance tests, this extension helps bring down end-to-end delay by about 150 ms on small frames. BUG=webrtc:5895 Review-Url: https://codereview.webrtc.org/2007743003 Cr-Commit-Position: refs/heads/master@{#13059}
2016-06-08 00:24:21 -07:00
send_playout_delay_ = true;
Merge min_ms and max_ms accessors in PlayoutDelayOracle to reduce CriticalSection enterencies and avoid potentional synchronisation issues. R=isheriff@chromium.org Review URL: https://codereview.webrtc.org/2312143002 . Cr-Commit-Position: refs/heads/master@{#14101}
2016-09-07 13:29:47 +02:00
playout_delay_.max_ms = playout_delay.max_ms;
Add sender controlled playout delay limits This CL adds support for an extension on RTP frames to allow the sender to specify the minimum and maximum playout delay limits. The receiver makes a best-effort attempt to keep the capture-to-render delay within this range. This allows different types of application to specify different end-to-end delay goals. For example gaming can support rendering of frames as soon as received on receiver to minimize delay. A movie playback application can specify a minimum playout delay to allow fixed buffering in presence of network jitter. There are no tests at this time and most of testing is done with chromium webrtc prototype. On chromoting performance tests, this extension helps bring down end-to-end delay by about 150 ms on small frames. BUG=webrtc:5895 Review-Url: https://codereview.webrtc.org/2007743003 Cr-Commit-Position: refs/heads/master@{#13059}
2016-06-08 00:24:21 -07:00
high_sequence_number_ = unwrapped_seq_num;
}
ssrc_ = ssrc;
}
// If an ACK is received on the packet containing the playout delay extension,
// we stop sending the extension on future packets.
void PlayoutDelayOracle::OnReceivedRtcpReportBlocks(
const ReportBlockList& report_blocks) {
rtc::CritScope lock(&crit_sect_);
for (const RTCPReportBlock& report_block : report_blocks) {
Renamed fields in rtp_rtcp_defines.h/RTCPReportBlock Continues on https://codereview.webrtc.org/2992043002 BUG=webrtc:8033 Review-Url: https://codereview.webrtc.org/2994633002 Cr-Commit-Position: refs/heads/master@{#19286}
2017-08-09 06:13:45 -07:00
if ((ssrc_ == report_block.source_ssrc) && send_playout_delay_ &&
(report_block.extended_highest_sequence_number >
high_sequence_number_)) {
Add sender controlled playout delay limits This CL adds support for an extension on RTP frames to allow the sender to specify the minimum and maximum playout delay limits. The receiver makes a best-effort attempt to keep the capture-to-render delay within this range. This allows different types of application to specify different end-to-end delay goals. For example gaming can support rendering of frames as soon as received on receiver to minimize delay. A movie playback application can specify a minimum playout delay to allow fixed buffering in presence of network jitter. There are no tests at this time and most of testing is done with chromium webrtc prototype. On chromoting performance tests, this extension helps bring down end-to-end delay by about 150 ms on small frames. BUG=webrtc:5895 Review-Url: https://codereview.webrtc.org/2007743003 Cr-Commit-Position: refs/heads/master@{#13059}
2016-06-08 00:24:21 -07:00
send_playout_delay_ = false;
}
}
}
} // namespace webrtc
Reference in New Issue Copy Permalink