网站开发概要设计书模板,新闻列表做的最好的网站,广告策划书目录,合肥做网站便宜mdyun介绍 近年来#xff0c;通过互联网进行实时通信变得越来越流行#xff0c;而 WebRTC 已成为通过网络实现实时通信的领先技术之一。WebRTC 使用多种协议#xff0c;包括实时传输协议 (RTP) 和实时控制协议 (RTCP)。 RTP负责通过网络传输音频和视频数据#xff0c;而RTCP负责…
介绍 近年来通过互联网进行实时通信变得越来越流行而 WebRTC 已成为通过网络实现实时通信的领先技术之一。WebRTC 使用多种协议包括实时传输协议 (RTP) 和实时控制协议 (RTCP)。 RTP负责通过网络传输音频和视频数据而RTCP负责监控网络状况并向发送方提供反馈。RTP和RTCP在同一网络上通信RTP使用偶数端口RTCP使用奇数端口。这允许两种协议使用相同的网络资源而不会互相干扰。在这篇文章中我们将讨论 RTP 和 RTCP 是什么以及它们如何协同工作以在 WebRTC 中实现实时通信。
实时传输协议 (RTP) 实时传输协议RTP是一种设计用于通过互联网传输音频和视频数据的协议。RTP 用于实时传输媒体流例如语音和视频。 RTP 负责将媒体数据打包成小数据包并通过网络传输。每个RTP数据包都包含一个序列号和时间戳用于确保数据包以正确的顺序和在正确的时间传送。RTP 数据包通过 UDP 传输延迟低非常适合实时通信。
实时控制协议 (RTCP) 实时控制协议 (RTCP) 是一种旨在提供 RTP 流量服务质量 (QoS) 反馈的协议。RTCP 用于监视网络状况例如数据包丢失和延迟并向发送方提供反馈。RTCP 数据包定期发送以提供有关 RTP 流质量的反馈。它们包含有关 RTP 流的统计信息包括发送和接收的数据包数量、丢失的数据包数量以及数据包之间的延迟。此信息可用于调整 RTP 流以提高音频或视频的质量。
了解视频压缩 我们不会深入研究视频压缩但我们会足够了解为什么 RTP 是这样设计的。视频压缩将视频编码为一种新的格式需要更少的比特来表示相同的视频。
有损和无损压缩 视频可以编码为无损没有信息丢失或有损信息可能丢失。RTP 通常使用有损压缩来防止高延迟流和更多丢包即使视频质量不太好。
帧内和帧间压缩 视频压缩有两种类型帧内压缩和帧间压缩。帧内压缩减少了用于描述单个视频帧的位数。相同的技术也用于压缩静态图片例如 JPEG 压缩方法。另一方面帧间压缩寻找不两次发送相同信息的方法因为视频是由许多图片组成的。
帧间类型
帧间压缩共有三种帧类型
I 帧- 无需任何其他内容即可解码的完整图片。P 帧- 仅包含与前一张图片相比的变化的部分图片。B 帧- 部分图片是对先前和未来图片的修改。
以下是三种帧类型的可视化。 显然视频压缩是一个有状态的过程在通过互联网传输时会带来挑战。这让我们想知道如果 I 帧的一部分丢失会发生什么P 帧如何确定要修改的内容随着视频压缩方法变得更加复杂这些问题变得更加紧迫。尽管如此RTP 和 RTCP 提供了一个解决方案。
RTP数据包结构
每个 RTP 数据包都具有以下结构如RFC中所定义 0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--------------------------------
|V2|P|X| CC |M| PT | sequence number |
--------------------------------
| Timestamp |
--------------------------------
| Synchronization Source (SSRC) identifier || Contributing Source (CSRC) identifiers |
| .... |
--------------------------------
| Payload |
--------------------------------Version (V)
Version始终设置为2。
Padding (P)
Padding是一个布尔值用于确定有效负载是否有填充。
有效负载的最后一个字节指示添加的填充字节数。
Extension (X) 如果设置RTP 标头将包含扩展。
CSRC Count (CC) 指的是有效负载之后和之前的标识符CSRC Count的数量。CSRCSSRC
Marker 该Marker位没有预定含义可以根据用户的需要使用。 在某些情况下它可能指示用户何时说话或者可能指示关键帧。
Payload Type (PT) 这Payload Type是该数据包携带的编解码器的唯一标识符。 对于 WebRTCPayload Type是动态的这意味着Payload Type一次调用中 VP8 的 可能与另一次调用中的 VP8 不同。Payload Types调用中的提供者确定到编解码器的映射Session Description。
Sequence Number 用于Sequence Number对流中的数据包进行排序。每发送一个数据包Sequence Number就会加一RTP 是被设计为在有损网络上有用这为接收方提供了一种检测数据包何时丢失的方法。
Timestamp Timestamp是该数据包的采样时刻。它不是一个全局时钟而是代表媒体流中已经过去了多少时间。例如如果多个 RTP 数据包都是同一视频帧的一部分则它们可以具有相同的时间戳。
Synchronization SourceSSRC An SSRC是该流的唯一标识符。这允许多个媒体流在单个 RTP 流上运行。
Contributing Source (CSRC) 这是一个列表用于传达哪些 SSRC 对此数据包做出了贡献。 这通常用于谈话指标。例如如果多个音频源在服务器端组合成单个 RTP 流则该字段可用于指示哪些输入流在给定时刻处于活动状态。
Payload 该字段包含实际的有效负载数据如果设置了填充标志则该数据可能以添加了多少填充字节的计数结束。
RTCP数据包结构
每个 RTCP 数据包都有以下结构
0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
--------------------------------
|V2|P| RC | PT | length |
--------------------------------
| Payload |
--------------------------------Version (V)
Version始终是2。
Padding (P) Padding是一个布尔值用于控制有效负载中是否包含填充。 有效负载的最后一个字节包括添加的填充字节的计数。
Reception Report Count (RC) 这表示此数据包中包含的报告数量。单个 RTCP 数据包可能包含多个事件。
Packet Type (PT) 这是 RTCP 数据包类型的唯一标识符。虽然 WebRTC 代理不一定需要支持所有这些类型但代理之间的支持可能存在差异。一些常见的数据包类型包括
192- 完整帧内请求 ( FIR)193- 否定确认 ( NACK)200- 发件人报告201- 接收者报告205- 通用 RTP 反馈206- 有效负载特定反馈包括PLI
RTCP数据包类型详细信息 RTCP 是一种灵活的协议支持多种类型的数据包。下面详细介绍了一些最常用的数据包类型。
PLI图像丢失指示/FIR完整帧内请求 FIR和消息都有PLI类似的目的向发送者请求完整的关键帧。然而PLI当解码器无法解码部分帧时专门使用这可能是由于数据包丢失或解码器崩溃造成的。 根据 RFC 5104FIR当数据包或帧丢失时不应使用这就是 的工作PLI。FIR用于出于其他原因请求关键帧例如当新成员进入视频会议并需要完整关键帧来开始解码视频流时。解码器将丢弃帧直到关键帧到达。 然而在实践中处理PLI和FIR数据包的软件将向编码器发送信号以在这两种情况下生成新的完整关键帧。 通常接收器会在连接后立即请求完整的关键帧以最大限度地缩短第一帧出现在用户屏幕上的时间。 PLI数据包是有效负载特定反馈消息的一部分。
NACKNegative Acknowledgement 当接收方发出 时NACK它会请求发送方重新传输单个 RTP 数据包。这通常是在数据包丢失或延迟时完成的。NACK比请求重新发送整个帧更好因为 RTP 将数据包分成小块并且接收方通常只丢失一小块。为了请求丢失的片段接收器创建带有 SSRC 和序列号的 RTCP 消息。如果发送方没有重新发送所请求的 RTP 数据包它将简单地忽略该消息。
发送者和接收者报告 这些报告对于在代理之间传输统计数据至关重要。它们有效地传达接收到的数据包的确切数量以及抖动级别。 此功能提供有价值的诊断信息并实现有效的拥塞控制。我们将在下面详细了解如何使用这些报告来克服不可靠的网络条件。
克服不可靠的网络 实时通信严重依赖网络。在理想的情况下带宽将是无限的并且数据包将立即到达。不幸的是网络是有限的并且条件可能会发生意外变化因此很难测量和观察网络性能。此外不同的硬件、软件和配置可能会导致不可预测的行为。 RTP/RTCP 运行在许多不同类型的网络上因此发送方和接收方之间的某些通信丢失是很常见的。由于它建立在 UDP 之上因此没有内置方法来重传数据包或处理拥塞控制。
测量和传达网络状态 RTP/RTCP 在各种网络类型和拓扑上运行因此发送方到接收方可能会发生通信丢失。由于它们建立在 UDP 之上因此没有数据包重传或拥塞控制的固有机制。 为了获得最佳的用户体验我们必须评估网络路径质量并适应其随时间的变化。要监控的关键特征是可用带宽在每个方向上可能不对称、往返时间和抖动往返时间的变化。我们的系统必须考虑数据包丢失并随着网络条件的变化传达这些属性的变化。
该协议有两个主要目标
估计网络支持的可用带宽在每个方向。在发送方和接收方之间传达网络特征。
接收者报告/发送者报告 接收方报告和发送方报告通过 RTCP 发送并在RFC 3550中定义。它们在端点之间传递网络状态。接收器报告传达网络质量包括数据包丢失、往返时间和抖动。这些报告与根据网络质量估计可用带宽的其他算法配合使用。 发送方和接收方报告SR 和 RR共同描绘了网络质量。它们按每个 SSRC 的时间表发送并用于估计可用带宽。发送方收到RR数据后估计可用带宽其中包含以下字段
丢失分数- 自上次接收器报告以来丢失的数据包百分比。丢失数据包的累积数量- 整个呼叫期间丢失的数据包数量。接收到的扩展最高序列号- 最后接收到的序列号以及已滚动的次数。到达间隔抖动- 整个呼叫的滚动抖动。最后发件人报告时间戳- 发件人的最后已知时间用于计算往返时间。 这些统计数据进一步输入带宽估计算法例如 GCCGoogle 拥塞控制该算法估计可用带宽进而驱动编码比特率和帧分辨率。
结论 总之RTP 和 RTCP 是 WebRTC 中实现实时通信的基本协议。RTP负责通过网络传输音频和视频数据而RTCP负责监控网络状况并向发送方提供反馈。这些协议共同实现了互联网上的高质量实时通信。对于任何有兴趣使用 WebRTC 开发实时通信应用程序的人来说了解 RTP 和 RTCP 如何协同工作至关重要。
参考
RFC3550RTP实时应用传输协议RFC5104带反馈的 RTP 视听配置文件中的编解码器控制消息RFC8888用于拥塞控制的 RTP 控制协议 (RTCP) 反馈
关于转载
转载此文请注明出处“引用于新睿云.弘电脑”否则请回避。
