翟海涌
摘要：随着视频压缩技术的日益成熟，数字视频监控产品逐渐成为了市场的主流。人们迫切希望网络技术能够成功地应用于数字视频监控领域，以使人们能够通过网络实现异地监控。正是在这种背景下，“基于网络的数字视频传输”课题研究日显重要。本文围绕网络视频传输的实时性和传输质量两大重要指标，从“解决传输层协议问题”入手，通过对TCP协议和RTP协议的比较，提出了“基于UDP协议的RTP实时视频传输”的设计思想，较好地保证了数字视频传输的实时性和服务质量。
关键词：数字视频；网络；传输层协议
1 引言
数字视频传输是人们利用视觉来获取信息的一种通信方式，它较之其它信息传递方式，具有确切性、直观性及高效率等特点。由于数字视频传输的大信息量和有限的传输带宽，使得视频的压缩编码、传输信道和网络协议的选择、IP组播技术（IP Multicast）以及基于Windows操作平台的软件实现成为了基于网络的数字视频传输应用中的关键技术。其中，传输信道和网络协议的选择至关重要，它将直接影响到数字视频传输的实时性能和通过网络传输以后客户端接收的视频图像质量。
图1给出了基于网络的数字视频传输的基本模型。本文将针对基于网络的数字视频传输应用中的网络传输协议的选择作以具体分析。
2 网络传输协议的选择集中在传输层
我们知道，ISO组织制订的OSI（Open System Interconnection）网络参考模型，将网络共分成7层结构，从下而上依次为：物理层、数据链路层、网络层、传输层、会话层、表示层及应用层。各层的功能都相互独立，每一层所实现的功能对上面一层来说都是透明的，每一层都只关心下一层所提供的服务。
物理层的任务是透明地传输比特流，数据链路层的任务是通过各种协议，在两个相邻节点间的线路上无差错地传送以帧为单位的数据，它们的功能已经由传输介质和网卡固化了，不能通过编程的方法进行改变，所以在编程设计时就不需要考虑这两层；网络层的任务是选择适当的路由，完成数据的打包和传送，在这一层，NetWare使用IPX协议，Unix和Windows则使用IP协议；传输层的任务是根据子网的特性最佳地利用网络资源，并以可靠和经济的方式为两端主机建立传输连接，以透明的方式传送报文，在这一层NetWare使用SPX协议，而Windows则使用TCP/UDP协议，Unix则使用TCP协议；会话层的任务是确定相互连接的主机之间信息的传递方式，即：全双工、半双工和单工，在局域网中一般不用考虑；表示层的任务是进行传输数据格式化和代码转换，一般用于异种机之间的通信，微机之间就不存在这些问题，所以这一层也不需要考虑；应用层的任务是确定进程之间通信的性质以满足用户的需要，它是我们编程的任务，但无须做协议的选择。由此看来，为了保证基于网络的数字视频传输的实时性和图像的质量，传输层协议的选择是整个设计和实现的关键。
Internet在IP层之上使用了两种传输协议：一种是传输控制协议TCP（Transmission Control Protocol），它是面向连接的网络协议；另一种是用户数据报协议UDP（User Datagram Protocol），它是无连接的网络协议。图2是网络的概念分层：
在对传输层协议进行分析比较之前，我们有必要认识一下“面向连接”和“无连接”的概念。面向连接服务是电话系统服务模式的抽象，即每一次完整的数据传输都要经过建立连接、使用连接、终止连接的过程。在数据的传输过程中，各数据分组不携带目的地址，而是使用连接号（Connect ID）。本质上，连接是一个管道，收发数据不但顺序一致，而且内容相同。TCP协议提供面向连接的虚电路服务。
无连接服务是邮政系统服务的抽象，每个分组都携带有完整的目的地址，各分组在系统中独立传送。无连接服务不能保证分组的先后顺序，不进行分组出错的恢复与重传，不保证传输的可靠性。UDP协议提供无连接的数据报服务。
3 TCP不适合实时传输视音频数据
IP网已被广泛使用在各种场合。其中TCP/IP协议是异种网络操作系统互连和通信的工业标准。系统构建在TCP/IP之上，可以拓宽其应用范围。但是，单纯的TCP/IP协议已经很难适应视音频通信，特别是连续的媒体流（如视频流）通信的要求。TCP协议是面向连接的协议，被用于各种网络上提供有序可靠数据传输的虚电路服务。它的重传机制和拥塞控制机制（Congestion Control Mechanism）都是不适合用于实时视音频传输的。
TCP/IP协议最初是为提供非实时数据业务而设计的。IP协议负责主机之间的数据传输，不进行检错和纠错。因此，经常发生数据丢失或失序现象。为保证数据的可靠传输，人们将TCP协议用于IP数据的传输，以提高接收端的检错和纠错能力。当检测到数据包丢失或错误时，就会要求发送端重新发送，这样一来就不可避免地引起了传输延时和耗用网络的带宽。因此传统的TCP/IP协议传输实时音频、视频数据的能力较差。当然在传输用于回放的视频和音频数据时，TCP协议也是一种选择。如果有足够大的缓冲区、充足的网络带宽，在TCP协议上，接近实时的视音频传输也是可能的。然而，如果在丢包率较高、网络状况不好的情况下，利用TCP协议进行视频或音频通信几乎是不可能的。
TCP和其它可靠的传输层协议如XTP不适合实时视音频传输的原因主要有以下几个方面：
3．1 TCP的重传机制
我们知道，在TCP/IP协议中，当发送方发现数据丢失时，它将要求重传丢失的数据包。然而这将需要一个甚至更多的周期（根据TCP/IP的快速重传机制，这将需要三个额外的帧延迟），这种重传对于实时性要求较高的视音频数据通信来说几乎是灾难性的，因为接收方不得不等待重传数据的到来，从而造成了延迟和断点（音频的不连续或视频的凝固等等）。
3．2 TCP的拥塞控制机制
TCP的拥塞控制机制在探测到有数据包丢失时，它就会减小它的拥塞窗口。而另一方面，音频、视频在特定的编码方式下，产生的编码数量（即码率）是不可能突然改变的。正确的拥塞控制应该是变换音频、视频信息的编码方式，调节视频信息的帧频或图像幅面的大小等等。
3．3 TCP报文头的大小
TCP不适合于实时视音频传输的另一个缺陷是，它的报文头比UDP的报文头大。TCP的报文头为40个字节，而UDP的报文头仅为12个字节。并且，这些可靠的传输层协议不能提供时间戳（Time Stamp）和编解码信息（Encoding Information），而这些信息恰恰是接收方（即客户端）的应用程序所需要的。因此TCP是不适合于视音频信息的实时传输的。
3．4 启动速度慢
即便是在网络运行状态良好、没有丢包的情况下，由于TCP的启动需要建立连接，因而在初始化的过程中，需要较长的时间，而在一个实时视音频传输应用中，尽量少的延迟正是我们所期望的。
由此可见，TCP协议是不适合用来传输实时视音频数据的，为了实现视音频数据的实时传输，我们需要寻求其它的途径。
4 RTP协议适合实时视音频传输
RTP（Real-Time Transport Protocol）/RTCP（Real-Time Transport Control Protocol）是一种应用型的传输层协议，它并不提供任何传输可靠性的保证和流量的拥塞控制机制。它是由IETF（Internet Engineering Task Force）为视音频的实时传输而设计的传输协议。RTP协议位于UDP协议之上，在功能上独立于下面的传输层（UDP）和网络层，但不能单独作为一个层次存在，通常是利用低层的UDP协议对实时视音频数据进行组播（Multicast）或单播（Unicast）,从而实现多点或单点视音频数据的传输。
UDP是一种无连接的数据报投递服务，虽然没有TCP那么可靠，并且无法保证实时视音频传输业务的服务质量（QoS）,需要RTCP实时监控数据传输和服务质量，但是，由于UDP的传输延时低于TCP，能与音频和视频流很好地匹配。因此，在实际应用中，RTP/RTCP/UDP用于音视频媒体，而TCP用于数据和控制信令的传输。
RTP协议被设计成能够为某种特定的应用提供服务的一种协议。实际上，RTP协议的实现已经被融合到应用程序中来。RTP没有连接的概念，它既可以建立在面向连接的底层协议上，也可以建立在面向无连接的底层协议上，因此RTP协议对传输层是独立的。RTP协议一般由两个部分组成：数据报文部分（RTP报文）和控制报文部分（RTCP）。
RTP报文由报文头和数据部分组成。RTP头格式如图3所示，固定头报文头开始的12个字节出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。
通过RTP报文头的结构我们注意到：RTP报文中没有一个“长度”字段，这是因为RTP把数据分段的任务交给了底层的协议UDP去处理了，由UDP协议进行数据的分段，再组成若干个UDP数据包进行传输。
RTP协议是用户携带具有实时特征的数据，与之作为配套的另一个协议是RTCP协议。RTCP是RTP的控制协议，它用于监视服务质量和正在进行的与会者会活上传递信息，它单独运行在底层协议上。根据协议规定，RTP和RTCP选用不同的网络端口号，RTP选择一个偶数位的端口号，而RTCP则选用下一个奇数位的端口号。RTCP是由接收方向发送的报文，它负责监视网络的服务质量、通信带宽以及网上传送的信息，并将这些信息发送给发送端。RTCP包周期性地向同一个组播网内的所有成员发送。
RTCP报文共有5类：SR（发送报告）、RR（接收报告）、SDES（源描述项）、（BYE表示标示）、APP（应用特定函数）。RTCP报文如图4所示。
RTCP的基本做法是周期性地向会话的所有参加者进行通信，采用和数据包分配传送的相同机制来发送控制包。和RTP协议相同，RTCP协议也要求下层协议提供复用手段（如，要UDP提供不同的端口号来实现复用）。RTCP的主要功能如下：
1、 数据传输的质量提供反馈，并提供QoS的检测
所有的接收方把它最近的接收情况报告给所有发送者，这些信息包括所接收到数据包的最大顺序号、丢失的包数、乱序包的数量以及用于估计传输时延的时间戳的信息。而这些信息反映了当前的网络状况，发送方在接收到这些信息后自动地调整它们的发送速率。
2、 提供不同媒体间的同步
例如，在视音频传输服务中，RTP源可能会有几种媒体（如视频和音频）需要传输，这些不同的媒体之间的同步需要依靠RTCP中包含的时钟信息和相关的RTP时间戳信息来进行同步。
3、 在会话的用户界面上显示会话参与者的标识
RTP报文中提供了SSRC字段来进行源标识，然而，进一步的会话参与者的描述是需要的。RTCP报文中的源描述（SEDS）提供了会话参与者的详尽描述，包括姓名、住址、E-mail等，主要是为会议电视提供更体贴的支持。当然，对于多视频服务器的组播模式也提供了很好的解决方案。
我们知道，视频流和音频流在时间轴上的连续性要求网络的实时传输及高带宽，同时又允许传输中存在一定的数据错误率及数据丢失率。由于RTP本身并不具有一种独立传输能力，它必须与低层网络协议结合才能完成数据的传输服务。又由于视频和音频在时间轴上的相关性不强，而数据的实时性要高于其可靠性，所以在UDP之上利用RTP/RTCP协议对媒体（视频和音频）流进行封装、打包和同步，可以使数字视音频信号的网络传输延时达到最小。
通过以上对RTP及RTCP报文的详尽分析，我们可以得到这样一个结论：与TCP协议相比较，RTP协议提供了一种更适合于实时视音频信息的传输机制。
5 结束语
如果接收端和发送端处于同一个局域网内，由于有充分的带宽保证，在满足视频传输的实时性方面，TCP也可以有比较好的表现，TCP和基于UDP的RTP的视频传输性能相差不大。由于在局域网内带宽不是主要矛盾，此时视频数据传输所表现出来的延时主要体现为处理延时，它是由处理机的处理能力以及采用的处理机制所决定的。这时，基于事件处理的多线程多缓冲区机制显得更胜一筹。但是当在广域网中进行视频数据传输时，此时的传输性能极大地取决于可用的带宽，由于TCP是面向连接的传输层协议，它的重传机制和拥塞控制机制，将使网络状况进一步恶化，从而带来灾难性的延时。同时，在这种网络环境下，通过TCP传输的视频数据，在接收端重建、回放时，断点非常明显，体现为明显的断断续续，传输的实时性和传输质量都无法保障。相对而言，采用RTP传输的视频数据的实时性和传输质量就要好得多。
摘自《电信建设》2002.8
|