搜索
你可能用过VOD，印象最深的可能不是点播的乐趣，而是差劲的影音质量，这里有片源的问题，也有影音制作、传输等方面的问题。新的流媒体应用要求互联网提供有服务质量保证(QoS)的传输，在现有的网络状况下，为人们提供更高级的视听享受。未来，流媒体的一个主要研究方向就是让——RTCP协议作为RTP协议的一个重要补充，配合传输层协议，保证了流媒体的实时性特征，满足了用户在IP网上对QoS的需求。RTCP以反馈机制实现对媒体服务的QoS控制，充分利用现有的网络资源，具有造价低、效果好的优点，是当前流媒体研究的一个热点。新的流媒体应用要求互联网提供有服务质量(QoS)保证的传输，在现有网络状况下，能为人们带来更高级的视听享受。互联网是一个基于包交换的通信网，初期的设计目标是要解决网络的连通性和高可靠性，并没有对实时性进行较多的考虑。为了在包交换网络上提供有服务质量保证的传输，必须解决预留资源、分类信息、时间同步等问题。基于IP的实时协议就是针对不同的侧重点，对原有的协议族进行改造，来满足实时通信的要求。这些协议主要分布在两层：网络层和传输层，属于网络层的有RSVP、DiffServ，属于传输层的有RTP、RTCP、RTSP等。RTP协议是互联网上广泛应用的流媒体传输协议。通常运行于RTP/UDP模式下，而UDP协议本身不提供任何传输可靠性保证，传输层的控制功能主要由它的控制部分RTCP协议来实现。RTCP协议是RTP协议的控制部分。RTP用来传递实时多媒体数据信息，除了携带多媒体数据外，它还给出了所携带负载的时间戳、顺序号等信息。为了可靠、高效地传送实时数据，RTP和RTCP必须配合使用。RTCP依靠反馈机制根据已经发送的数据报文对带宽进行调整、优化，从而实现对流媒体服务的QoS控制。RTCP反馈可以直接作用于编码、发送、甚至协议选择环节。作用于直播编码RTCP监视RTP传输的服务质量，定期将RTCP报文发送给流媒体服务器。RTCP报文包括已发送数据包的数量、丢失数据包的数量等统计资料，直播服务器可以利用这些信息动态地改变编码质量。例如，对MPEG-4编码来说，如果接收报告(RR)报文传送丢包率大于20%，则改变了编码码率。这项应用需要建立在多码率应用基础之上才能收到更好的使用效果。MPEG在视频编码压缩上采取用三种类型的图像：帧内图（IntaPicture，I）、预测图（PredictedPictures，P）和差补图，即双向预测图（BidirectionalPrediction，B）。I帧可提供随机存取的存放位置，但压缩比不大；P帧可以由I帧或前面的P帧进行预测，压缩比大于I帧；B帧是通过先前和后继的信息进行预测，因此压缩效果最显著。一个视频流序列沿时间轴方向的顺序排列如：IBBPBBPBBIBBPBBP......如此的序列受两个参数M和N约束。M为相邻的I帧与P帧和相邻的两个P帧间的距离，上面的序列M为3；N为相邻的I帧的距离，上面序列N为9。根据MPEG-4码流的特点，设计RTCP反馈直接作用于编码参数M、N的调节。从直观上来看，就是在改变编码的码率。图1给出了流媒体直播系统结构图。在播放进行中动态地实现调整编码码率需要实现单文件多码率技术。在现有的Linux流媒体服务器中，采用单服务器多编码器的技术实现分级的多码率服务。RTCP反馈实际作用于编码器的选择。在服务启动之前，服务器给客户端发送测试包，通过客户端的RTCP反馈RR报文，选择适合客户端网络状况的编码器。服务建立之后，在数据传送过程中还不能实现不同编码器之间的切换。这时候RTCP的统计报文通过有效调节传输速率控制流媒体服务的QoS。作用于数据发送环节对于点播服务器来说，大量视频数据已经完成编码。RTCP反馈信息就可以改变数据发送速率，或对媒体数据进行选择性丢弃。图2显示的是流媒体点播系统框架示意图。当RR报文传送丢包率、接收包总数等统计信息超过临界值，如丢包率超过20%，则改变发包速率。正常情况下，传送一个700Kbps左右的媒体文件，服务器每秒传送大于700个左右IP报文。一旦解析发现接收端丢包现象严重（超过20%），则发包速率降低。设定接收端缓冲2秒数据，当(oldrate-newrate)*time2秒，则播放出现不连续，甚至停止。调整发包速率的方法虽然在一定程度上能够缓解暂时的网络拥塞造成的影响，但是却不能从本质上减轻网络负载，缓解拥塞状况。更为有效的办法是在服务器端就对数据包进行有选择性的丢弃。用MPEG-4压缩多媒体数据，I帧数据相对独立，是解码时必须的数据，因此应尽量保留；P帧需要与相邻的I帧配合，进行运动图像恢复，重要程度仅次于I帧;P帧的每帧数据量最少，一般可为I帧的1/10，但是压缩的多媒体数据中大量的都是P帧，因此它的总数据量并不少。包含P帧的IP数据报文相对较小，更容易在网络上造成拥塞。因此当监测到丢包率升高时，服务器按照一定规则丢弃一些P帧。这样发送到网络上的P帧会大大减少，有效地缓解了网络负荷。对于按服务流量进行计费的用户来说，用这种方法可使服务质量和流量能基本一致，是一种比较合理的做法。作用于传输协议协商1.协商策略RTP协议有与具体的承载网络分离的特点。因此在理论上底层传输协议既可以用TCP协议，也可以用UDP协议。TCP/IP网络传输结构无疑是目前最成熟、最可靠、应用最广泛的传输方式，但在目前的流媒体应用中，几乎所有的应用在网络传输层都使用RTP/UDP。UDP协议有传输效率高的特点。这是因为UDP不需要建立连接，启动时间短，传输时延短。同时UDP协议也有它无法克服的弊端:首先是可靠性无法保障;其次，RTCP报文的传输虽然与RTP使用不同的端口，但是RTCP的反馈数据报文本身基于UDP，其反馈速度直接受到网络环境的影响，其反馈控制效果不理想;最后，RTCP协议本身比较新，拥塞控制算法不是很完善。TCP协议相对比较成熟，在拥塞控制、网络安全方面有较大优势。但是与UDP协议相比，它的效率相对比较低，启动时间长，实现起来也更复杂。TCP协议是基于连接的传输协议，网络开销大，因此可以在网络状况较好的情况下选用。相反，在网络条件不是很好的情况下，如带宽较窄，发生拥塞，就可以选用相对比较简洁的UDP协议。协商协议过程如图3所示。2.具体实现在服务建立之前，首先由服务器发送测试数据，如码率3Mbps。由于RTCP协议专用于用户规模很小的情况下，发送RTCP报文间隔至少为5秒，第一个RTCP包发送间隔为1/2最小间隔，即2.5秒。这是一个用户无法接受的启动时间，因此需要对RTCP协议进行相应的修改。TCP协议的超时定时器一般设为200ms，而这也是一个用户所能接受的延迟。以3Mbps码率发送测试数据200ms，当发送测试数据结束时，接收端立即发送包含统计信息的RR报文给服务器。当丢包超过某个阈值时，服务器还是选用传统的UDP协议进行传输。否则，选用TCP协议进行传输。3.解决的问题要实现RTP/TCP传输模式，必须解决以下问题：如何将独立的RTP数据报文完整地传送到客户端，原因是与UDP相比，TCP传输机制以数据流的格式传输，数据报文无边界，如果不加以控制，以恒定的长度从TCP协议栈收取RTP数据报文，肯定无法得到独立的RTP数据报文并产生报文丢失。将TCP数据流分段的方法有许多，为了尽量提高传输效率，这里采用修改上层RTP协议的方法来实现TCP数据报文的分段和拼装,如图4所示。在TCP承载RTP协议的情况下，所有的数据报文以流的方式顺序地发送，在客户端也依次顺序被接收。因此RTP报文头的SequenceNumber数据项就失去了原来设计的意义。改造RTP协议的报文头，在SequenceNumber数据项的位置写入数据包的尺寸。这样就可以先接收RTP包头，然后根据解析出来的包长度再接收RTP数据部分。实现拼装的工作主要在客户端，接收RTP数据后，如果检测到所接收数据比实际RTP数据报文长度小，客户端将继续循环接收所缺少长度的数据报文，进行拼接，直至接收到完整的RTP数据报文后，再对报文进行分析和解码。这一过程得以实现的前提是TCP的可靠传输机制。在RTP/TCP模式下，传输控制功能主要由TCP协议完成，RTCP协议本身的许多冗余功能应该删除。在RTP/UDP传输模式下，RTCP数据控制报文约占报文总数量的5%，而发送报告(SR)和接收报告(RR)数据报文占所有RTCP数据控制报文总量的99%。因此，在RTP/TCP传输模式下，由于RTCP只保留了很少的控制功能，将继续使用UDP协议作为底层传输协议，其报文数量不会对网络负载造成影响。测试结果测试环境为目前正在开发的Linux流媒体服务器系统，服务器片源为基于MPEG-4编码的可流化视频文件。服务器端采用Linux操作系统和10M/100M自适应网卡;客户端采用Windows2000Professional操作系统和10M/100M自适应网卡。作用于直播编码系统真正意义上的平滑码率调节需要在单文件多码率压缩的基础上实现。现有系统采用多编码器实现分级多码率服务。RTCP的反馈作用实际应用于编码器的选择，在局域网中试验运行，可以充分利用带宽资源，并能保证较高的服务质量。作用于点播系统发包环节因为发生网络拥塞一般为暂时网络行为，采用降低发包速率的方法，在局域网环境下试验运行，基本能够满足QoS的要求，图像流畅。采用根据不同的数据类型进行选择性丢弃的方法，算法比较复杂，服务器负荷较重，在传送高码率媒体数据时性能优于调整发包率的方法。作用于UDP/TCP协议的协商RTP/TCP和RTP/UDP两种模式仅在传输层有所不同。两种模式下的RTCP控制报文仍使用UDP协议传输。在局域网中试验运行，对于512kbps的低中码率MPEG-4流，应用UDP协议传输，高于1100kbps的高码率MPEG-4流应用TCP协议传输，都能得到流畅、清晰的画面，几乎没有马赛克。同样环境下，只采用传统的UDP协议，传送高码率视频流，就会出现跳帧和局部马赛克，影响服务质量