目录
二、基于C/S架构的完整RTP/RTCP的H264/H265视频传输方案
一、简介
在当今的数字时代,视频通信已成为互联网的基石之一。从在线教育到远程工作,再到实时监控,视频流的传输技术无处不在。在这些应用中,保证高效、稳定的视频传输至关重要。本文旨在介绍一种基于客户端/服务器(C/S)架构的实时传输协议(RTP)和实时传输控制协议(RTCP)的H264/H265视频传输方案。
二、基于C/S架构的完整RTP/RTCP的H264/H265视频传输方案
1、什么是C/S架构?
在C/S架构中,客户端负责向服务器发送请求并接收服务器响应,而服务器则处理这些请求并管理资源。在视频流传输中,服务器通常负责视频的编码和分发,而客户端则负责解码和播放。
2、RTP/RTCP协议简介
RTP(Real-Time Transport Protocol)是一种网络协议,用于传输实时数据,如音频和视频。它广泛用于通信和娱乐系统中的流媒体。RTCP(Real-Time Transport Control Protocol)是RTP的姊妹协议,用于监控数据传输质量,并提供关于媒体流的统计信息。
3、H264/H265编码简介
H264和H265是视频压缩标准,分别被广泛应用在各种视频通信和媒体存储中。H265是H264的后继者,提供更高效的视频压缩,使得在相同的质量下,所需的带宽更少。
3.1、服务器端:
负责视频源的采集、编码(H264/H265)、打包成RTP格式,并通过网络发送到客户端。同时,服务器还需要处理RTCP报告,用于监控网络状况和质量控制;RTCP分析模块负责产生和发送RTCP包并分析接收到的RTCP包;QoS反馈控制模块则根据RR报文反馈信息动态的对发送速率进行调整;发送缓冲模块则设置端口发送RTP、RTCP包。
3.2、客户端:
负责接收RTP流,进行解码、渲染和播放;RTCP模块根据SR报文统计关键信息,产生并发送RR包。然后,在VS2019下用Socket编程,完成基于RTP/UDP/IP的H264/H265视频传输,并在局域网内运行较好。
基于RTP/UDP/lP的H264/H265视频传输结构设计;对于H264视频的实时传输应用来说,TCP的重传机制引入的时延和抖动是无法容忍的,因此我们采用UDP传输协议。但是UDP协议本身是面向无连接的,不能提供质量保证。而基于UDP之上的高层协议RTP/RTCP可以一起提供流量控制和拥塞控制服务。图给出了基于RTP/UDP/IP的H264/H265视频传输的框架。
图1-1 基于RTP/UDP/IP的H264/H265视频传输流程图
H264/H265视频流的RTP封装策略
从图1-1可以看出,H264/H265视频数据首先经RTP进行封装,打包成适合网络传输的数据包才能进行传输。所以,如何设计合适的RTP封装策略对H264/H265视频数据进行封装是十分重要的。一般来说,在H264/H265中,RTP封装应该遵循几个设计原则:
1、较低的开销,因此MTU的尺寸应该限制在100—64K字节范围内。
2、易于区分分组的重要性,而不必对分组内的数据解码。
3、应能检测到数据的类型,而不需解码整个数据流,并能根据编码流之间的相关性丢弃无用数据,如网关应能检测A型分割的丢失,并能丢弃相应的B型和C型分割。
4、应支持将一个NALU拆分为若干个RTP包:不同大小的输入图片决定了NALU的长度可能会大于MTU,只有拆分后才会避免IP层在传输时出现分片。
5、支持将多个NALU汇集在一个RTP分组中,即在一个RTP包中传输超过一个NALU,当多个图片的编码输出小于M1IU时就考虑此模式,以提高网络传输效率。
RTP载荷封装设计:
本文的网络传输是基于IP协议,所以最大传输单元(MTU)最大为1500字节,在使用IP/UDP/RTP的协议层次结构的时候,这其中包括至少20字节的IP头,8字节的UDP头,以及12字节的RTP头。这样,头信息至少要占用40个字节,那么RTP载荷的最大尺寸为1460字节。
图1-2 网络传输中H264/H265的封装格式
一方面,如果每个IP分组都填满1500字节,那么协议头的开销为2.7%,如果RTP载荷的长度为730字节,协议头的开销仍达到5.3%,而假设 RTP载荷的长度不到40字节,那么将有50%的开销用于头部,这将对网络造成严重资源浪费。另一方面,如果将要封装进RTP载荷的数据大于1460字节,并且我们没有在应用层数据装载迸RTP包之前进行载荷分割,将会产生大于MTU的包。在IP层其将会被分割成几个小于MTU尺寸的包, 这样将会无法检测数据是否丢失。因为IP和UDP协议都没有提供分组到达的检测,如果分割后第一个包成功接收而后续的包丢失,由于只有第一个包中包含有完 整的RTP头信息,而RTP头中没有关于载荷长度的标识,因此判断不出该RTP包是否有分割丢失,只能认为完整的接收了。并且在IP层的分割无法在应用层 实现保护从而降低了非平等包含方案的效果。由于UDP数据分组小于64K字节,而且一个片的长度对某些应用场合来说有点太小,所以应用层的打包也是RTP打包机制的一个必要部分。最新的RFC3984标准中提供了针对H264/H265媒体流的RTP负载格式,主要有三种: 单个NAL单元分组、聚合分组、片分组。
NAL单元单一打包,将一个NAL单元封装进一个包中,也就是说RTP负载中只包含一个NAL单元,NAL头部兼作RTP头部。RTP头部类型即NAL单元类型1-23,如下图所示:
图1-3 NAL单元类型及其名称
NAL单元的重组 此分组类型用于将多个NAL单元聚合在一个RTP分组中。一些H264/H265的NAL单元的大小,如SEI NAL单元、参数集等都非常小,有些只有几个字节,因此应该把它们组合到一个RTP包中,将会有利于减小头标(RTP/UDP/IP)的开销。目前存在着两种类型聚合分组:
NAL单元的分割:
将一个NAL单元分割,使用多个RTP分组进行传输。共有两个类型FU—A和FU—B,单元类型中分别为28和29。根据IP层MTU的大小,对大尺寸的NALU必须要进行分割,可以在分别在两个层次上进行分割:
1)、视频编码层VCL上的分割
为了适应网络MTU的尺寸,可以使用编码器来选择编码Slice NALU的大小,从而使其提供较好的性能。一般是对编码Slice的大小进行调整,使其小于1460字节,以免IP层的分割。
2)、网络提取层NAL上的分割 在网络提取层上对NALU的分割主要是采用分片单元方案,H264/H265标准中提出了分割机制,可以使NAL单元的尺寸小于1460字节。注意:此方式是针对同一个NAL单元进行分割的,不适用于聚合分组。一个NAL单元采用分割分组后,每个RTP分组序列号依次递增l,RTP时间戳相同且惟一。NAL单元的分割是RTP打包机制的一个重要环节,总结其分割机制主要有如下几个特点:
- 分割NALU时,是以RTP次序号升序进行传输。在序列号不循环的前提下,属于前一帧图像的所有图像片包以及A/B/C数据分割包的序列号要小于后帧图像中的图像片及数据分割包的序列号。
- 一个符号机制来标记一个分割的NALU是第一个还是最后一个NAL单元。
- 存在另外一个符号机制用来检测是否有丢失的分块。
- 辅助增强信息包和头信息包可以任意时间发送。
- 同一帧图像中的图像片可以以任意顺序发送,但是对于低时延要求的网络系统,最好是以他们原始的编码顺序来发送。
1)、单一时间聚合分组(STAP):包括单一时间聚合分组A(STAP—A)和单一时间聚合分组B(STAP—B),按时间戳进行组合,他们的NAL单元具有相同的时间戳,一般用于低延迟环境。STAP—ASTAP—B的单元类型分别为24和25。
2)、多时间聚合分组(MTAP):包括16比特偏移多时间聚合分组(MTAPl6)和24比特偏移多时间聚合分组 (MTAP24)不同时间戳也可以组合,一般用于高延迟的网络环境,比如流媒体应用。它的打包方案相对复杂,但是大大增强了基于流媒体的H264/H265的性能。MTAPl6 MTAP24的单元类型分别为26和27。
RTP包的封装流程设计
根据H264/H265NAL单元的分割重组的性质以及RTP打包规则,本文实行的对RTP打包的设计如下:
1)、若接收到的NAL单元小于MAX—SIZE(此时MAX-sIZE为设定的最大传输单元),则对它进行单一打包,也就是将此NAL单元直接放进RTP包的载荷部分,生成一个RTP包。
2)、若接收到的NAL单元大于MAx—SIZE字节,则对它进行分割,然后对分割后的NAL单元进行步骤1方式打包。分割方案如下:
其中Nsize是分割前的NAL单元大小,N是分割后NAL单元的大小。K分割后的单元数。分割后最后一个单元的大小可能会小于N,这时必须使用RTP载荷填充是其同前面的分块大小相同,此时RTP头中的填充标识位值为1。
3)、对SEI,参数集等小NAL单元重组,将它们合并到一个RTP包中。虽然步骤3中的重组方案可以减小IP/UDP/RTP头部开销,但是对于包丢失率比较高的网络环境,这意味着一个RTP包的丢失可能会导致多片的丢失,往往一个片中就有一个P图像,解码后的视频质量必然会严重下降。因此,在丢失率的网络中可以采用NAL单元的重组方案,而在高丢失率的网络环境中采用NAL单元重组时要进行有效的差错控制.在本文中不使用重组方案。
4、RTP/RTCP包的封装实现
4.1、RTP包封装设计
4.2、RTCP包的封装设计
RTCP报文封装在UDP数据报中进行传输,发送时使用比它所属的RTP流的端口号大1的协议号(RTP使用偶数号,RTCP使用奇数号)。以下是RTCP头部数据结构:
三、安全性考虑
视频通信时,安全性也是一个重要考虑。可以使用SRTP(Secure Real-time Transport Protocol)来加密RTP包,确保传输过程中的数据安全。
四、总结
基于C/S架构的RTP/RTCP的H264/H265视频传输方案为实时视频流提供了一种高效、稳定且可适应网络状况变化的解决方案。通过精心设计的编码、打包、传输、流量控制及错误处理机制,可以确保即使在网络状况不佳的情况下,也能提供尽可能好的视频观看体验。随着技术的发展,这些方案将继续演化,以满足日益增长的视频通信需求。
参考文章: