移动流媒体业务的技术与标准

移动流媒体业务的技术与标准

作者: 吴伟来源: 《通信技术与标准》发布时间: 2005-10-01

摘要：本文首先介绍了移动流媒体业务的概念，以及流媒体的编解码类型，随后重点描述了实现移动流媒体业务的相关协议，最后介绍了相关标准的进展情况。

关键词：移动流媒体 Streaming 3GPP RTSP SDP RTP

1 引言

流媒体业务是从Internet上发展起来的一种多媒体应用，指使用流（Streaming）方式在网络上传输的多媒体文件，包括音频、视频和动画等。

流媒体传输技术的主要特点是以流（streaming）的形式进行多媒体数据的传输。把连续的影像和声音信息经过压缩处理后放到网络服务器上，客户端在播放前并不需要下载整个媒体文件，而是在将缓存区中已经收到的信息进行播放的同时，多媒体文件的剩余部分将持续不断地从服务器下载到客户端，即“边下载，边播放”。这样就避免了用户在收看或收听媒体流的时候要花费一段时间把完整的文件下载到客户端，可以给用户带来“实时播放”的业务感知体验。

2 移动流媒体业务

移动流媒体业务就是流媒体技术在移动网络和终端上的应用，主要是利用目前2.5G或3G的移动通信网，为手机终端提供音频、视频的流媒体服务。移动流媒体业务的内容包括新闻资讯、影视、MTV、体育、教育、行业和专项应用等多种形式。

移动流媒体业务根据数据内容的播放方式可以分为三种业务类型：

●流媒体点播（VOD)：内容提供商将预先录制好的多媒体内容编码压缩成相应格式，存放在内容服务器

上并把内容的描述信息以及链接放置在流媒体的门户网站上。最终用户就可以通过访问门户网站，发现感兴趣的内容，有选择的进行播放。

●流媒体直播：流媒体编码服务器将实时信号编码压缩成相应的格式，并经由流媒体服务器分发到用户的终端播放器。根据实时内容信号源的不同，又可以分为电视直播、远程监控等。

●下载播放：用户将流媒体内容下载并存储到本地终端中，然后可以选择在任意时间进行播放。对于下载播放，主要的限制指标是终端的处理能力和终端的存储能力，内容提供商可以制作出较高质量的视音频内容(高带宽、高帧速率)，但需要考虑内容的下载时间及终端的存储空间。

移动流媒体技术是网络音视频技术和移动通讯技术发展到一定阶段的产物，它是融合很多网络技术之后所产生的技术，它会涉及到流媒体数据的采集、压缩、存储，无线网络通信，以及移动终端等多项技术。

由于流媒体的技术特点，决定了其在移动网络中的广阔应用前景。首先，流媒体技术有效降低对传输带宽和抖动的要求，使得在无线传输环境实现实时媒体播放业务成为可能。移动终端体积小、低能耗的要求决定了有限的存储空间，而媒体文件不需要在终端中保存，避免了对存储空间的要求。其次，有效的版权保护，能够确保移动流媒体应用的商用模式。

随着第三代移动通信技术的逐步成熟，将移动流媒体技术引入移动增值业务，已经成为目前全球范围内移动业务研究的热点之一。目前3GPP、3GPP2等标准化组织早已经开展了移动流媒体的应用研究工作，并已经制定了相应的标准。

3 移动流媒体的编解码类型

移动流媒体系统所支持的媒体内容编解码格式与业务类型无关，即无论是点播、直播，还是下载播放，这些格式都是适用的。

依据3GPP的PSS规范，UMTS系统的移动分组流媒体支持的编码类型包含视频、音频、静态图像、位图、向量图、普通文本和定时文本等，其中音频和视频的编解码类型可以有多种组合。本文主要描述视频与音频

媒体编码格式的要求。

根据3GPP R6的PSS规范，视频的媒体编解码类型主要有三种：H.263、MPEG-4和H.264。具体包括：

● H.263 profile 0 Level 45；

● H.263 profile 3 Level 45；

● MPEG-4 Visual Simple Profile level 0b；

● H.264(AVC) Baseline Profile Level 1b，且constraint_set1_flag=1，不要求输出的时间顺序。

音频媒体编解码方面，包含4种：

● Enhanced aacPlus；

● Extended AMR-WB；

● MPEG-4 AAC Low Complexity (AAC-LC)；

● MPEG?4 AAC Long Term Prediction (AAC-LTP)。

其中，MPEG-4音频解码器支持的最高采样率为48kHz。所支持的通道配置为mono（1/0）和stereo（2/0）。对于AAC-LC或AAC-LTP流，应在SDP“a＝fmtp”行中包含MIME参数“profile-level-id”和“object”。其值如表1所示：

4 实现移动流媒体业务的相关协议

本章主要介绍会话建立、RTSP、SDP、RTP/RTCP等移动流媒体的重要协议，以及这些协议用于移动应用的扩展。

实现移动流媒体业务的协议栈如图1所示。其中，视频、音频等流媒体数据主要通过RTP/UDP承载，而一些静态的图像、文本则可以使用HTTP进行承载。对于能力交换（Capbility Exchange）和表示描述（Presentation Description）可以使用HTTP或者RTSP进行封装，这取决于不同的实现方式。RTSP和SDP用于会话建立和控制，MIME描述媒体类型，RTP是流媒体负载的传输协议。

4.1 会话建立

会话建立是指移动流媒体客户端获得初始会话描述的方法。初始会话描述可能是一个表示描述、或者一个场景描述、或者仅仅是一个指向该内容的URL。移动流媒体客户端应当支持按以下格式定义的初始会话描述：SMIL、SDP或者简单的RTSP URL。

除了“rtsp://”以外，移动流媒体客户端还应该支持以“file://”（用于本地存储的文件）和“http://”（用于通过HTTP协议分发的表示描述或场景描述）开头的指向有效初始会话描述的URL，移动流媒体客户端应支持至少其中一种。三种输入举例如下：

●file://temp/morning_news.smil；

●http://mediaportal/morning_news.sdp；

● rtsp://mediaportal/morning_news.3gp

或rtsp://mediaportal/morning_news.3g2。

4.2 实时流媒体协议（RTSP）

RTSP（Real-time Streaming Protocol）是由RealNetworks和Netscape共同提出的一种协议，它定义了如何使一对多应用程序有效地通过IP网络传送多媒体数据。

连续的媒体是只有内在时间线的媒体。不连续的媒体则不包含自己的时间元素。话音、音频和视频属于连续的媒体，而静态图像和文本则是不连续的媒体。对于不连续的媒体的传输，例如矢量图、同步文本和合成音频，可以采用HTTP/TCP/IP协议。在这种情况下，由于HTTP已经具备这些功能，因此不需要一个独立的会话建立和控制协议。而对于使用RTP/UDP/IP的连续媒体流则需要一个会话控制协议来建立并控制独立的媒体流。流媒体业务使用RTSP协议来进行会话的建立和控制。

RTSP在体系结构上位于RTP、RTCP之上，它使用TCP或RTP完成数据传输。与HTTP相比，RTP传送的是多媒体数据，而HTTP传送HTML。在使用RTSP时，客户机和服务器均可发出请求，也就是说RTSP可双向服务，而HTTP的请求是由客户机发出，服务器进行响应。

RTSP的主要命令：DESCRIBE、PLAY、PAUSE、SET_PARAMETER、TEARDOWN、OPTIONS、SETUP。

3GPP的PSS规范中对于RTSP协议在移动分组流媒体中的应用定义了一些扩展字段，主要包括：

● Range头字段，并在PLAY的响应中包含这个字段；

● Bandwidth头字段；

● 3GPP-link-Char头字段：用于移动流媒体客户端向移动流媒体服务器报告无线链路特性；

● 3GPP-Adaptation头字段：用于移动流媒体客户端设置速率自适应参数；

● QoE头字段：用于移动流媒体客户端和服务器协商移动流媒体客户端应发送哪些QoS Metrics，以什么样的频率发送以及如何取消发送这些Metrics；

● Video Buffering头字段：用于Buffer的管理。

4.3 会话描述协议（SDP）

RTSP需要一个表示描述（Presentation Description），以便说明一个流媒体会话的基本属性，包括媒体类型和格式、所需要的传输带宽、播放的时间范围、所需Buffer信息等。作为在移动网络中应用的一种带宽和时延敏感的业务，这些信息对于保证移动终端用户的业务感受是非常重要的。

SDP协议最初用于描述SIP会话中支持的媒体类型，只是一种用于会话描述的格式（协议），它并不是一个传输协议，也不包含在媒体的编解码之中，而是用于在不同传输协议间的传递消息的通知协议，其主要目的是解决多媒体会话通知、邀请和会话的初始化工作。

3GPP的PSS规范中使用SDP协议实现RTSP的表示描述，并对SDP进行了必要的扩展，以便满足流媒体业务在移动网络中QoS需求。

SDP消息中包含两层：会话层和媒体层。一个会话描述中可能包含一个或多个媒体层的信息。SDP消息的基本内容包括：

●会话信息：

■会话名和目的；

■会话时间；

■会话使用的带宽；

■会话的用户信息；

●媒体信息：

■媒体类型，例如：视频或音频；

■传输协议，例如：RTP/UDP/IP；

■媒体格式，例如：H.263视频或者MPEG视频；

■多播地址和媒体传输端口（IP多播会话）；

■ IP单播会话的联系地址和媒体传输端口等。

DP会话描述由许多文本行组成。文本行的格式为：类型＝值。其中“类型”是一个字母，“值”是结构化的文本串。例如：

m = video 53000 RTP/AVP 31

其中：m代表这一行代表媒体信息；video代表是视频流；53000代表UDP端口号是53000；RTP/AVP指媒体传输协议使用RTP/AVP；31代表媒体格式使用H.261并且使用90KHz的时钟。

对于移动流媒体应用，3GPP在PSS规范中定义了一些扩展。SDP在移动流媒体的扩展要求包括带宽参数扩展、用于Buffer管理的扩展、完整性保护扩展等3GPP扩展要求。

移动终端需要使用SDP中的带宽（Bandwidth）字段，以便正确设置QoS参数。因此，移动流媒体服务器应在SDP中的媒体层为每个媒体流包括“b=AS:”、“b=TIAS:”和“a=maxprate”字段，并且在会话层包含“b=TIAS:”和“a=maxprate”字段。当客户端接收到SDP，它将忽略会话层的“b=AS:”参数，并且从相关流的媒体层带宽参数的值来计算会话需要的带宽。若会话层具有“b=TIAS:”和“a=maxprate”参数，由于汇聚多个媒体流时会话层能够提供所需会话带宽更为准确的描述，则优先使用会话层的这个参数，而不是媒体层的参数。

此外，3GPP的PSS规范中对于SDP中的会话层和媒体层都定义了带宽信息参数的两个扩展字段：

●“b=RS:”：为发送者（即流媒体服务器）分配的RTCP带宽；

●“b=RR:”：为接收者（即移动流媒体终端）分配的RTCP带宽。

流媒体服务器在SDP的媒体层包含每个媒体流的“b=RS:”和“b=RR:”字段。

为满足移动网络提供视频流媒体业务的性能要求或速率适配，3GPP的PSS规范也定义了一些扩展字段：

● "a=X-predecbufsize:"；

● "a=X-initpredecbufperiod:"；

● "a=X-initpostdecbufperiod:"；

● "a=X-decbyterate:"；

● "a=3gpp-videopostdecbufsize:"。

对于H.263格式的流媒体文件，SDP媒体层定义了framesize扩展字段。该字段定义了H.263流的最大视频帧的长度，便于终端分配适当大小的缓冲空间。格式如下：“a=framesize: -”。

3GPP还定义了一些SDP会话层的扩展字段，用于支持会话的完整性保护，包括：

● "a=3GPP-Integrity-Key"；

● "a=3GPP-SRTP-Config"；

● "a=3GPP-SDP-Auth"。

4.4 数据传输协议RTP与RTCP

为了传输会话控制信息和媒体信息，移动流媒体客户端和服务器应支持基于IP的网络接口。控制信息和媒体信息基于TCP/IP和UDP/IP传输。

移动流媒体的业务定义是按照实时或点播方式通过移动 缦蚴只 斩私 幸羰悠倒悴ィ 嫦蛄 拥腡CP 需要较多的开销，所以不适合移动流媒体的应用。移动流媒体传输一般采用实时传输协议RTP/UDP来传输实时多媒体数据，以获得较小的时延和减少数据开销。

RTP（Realtime Transport Protocol）实时数据传输协议是针对Internet上多媒体数据流的一个传输协议，由IETF作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠

RTCP提供这些服务。

RTCP（Realtime Transport Control Protocol）是RTP的控制协议，负责管理传输质量，在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。

RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，适合传送网上的实时数据。

RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。

RTP只是保证同一媒体流的时间戳功能，但是对于同时需要不同媒体流（音频＋视频）的业务时，RTCP 把时间戳和实时时钟联系起来，保证了媒体的同步，同时RTCP保证参与会话的成员反馈通信信息，从而保证通信的质量。

RTCP包的主要类型包括：

● SR：发送报告，发送者的发送和接收信息的统计；

● RR：接收报告，非发送者的接收信息的统计；

● SDES：信息源的描述；

● BYE：会话参与者会话结束标志；

● APP：某种应用功能。

几个单独的RTCP包可以组合成混合RTCP包进行传输。

3GPP对用于移动流媒体传输的RTP/RTCP也进行了一些扩展，以支持传输的完整性、RTP重传、拥塞控制和速率自适应等功能。

4.5 能力交换协议

在移动流媒体业务中，终端能力协商是一个重要的功能，它使得流媒体服务器可以提供广泛的内容给多种类型的客户端设备。其另一个重要功能是在不同版本的移动流媒体间提供平滑转换。因此，移动流媒体客户端和服务器应支持能力交换。

用户终端档案服务器（User Agent Profile）用于存储用户参数和设备功能信息。这些信息可用于控制如何向移动用户提供流媒体内容。

图2概括性说明终端能力协商机制。

5 移动流媒体标准进展

在移动流媒体技术的标准化方面，移动分组流媒体主要在3GPP进行规范，3GPP2对用于cdma2000系统的移动流媒体文件格式有所规定。

3GPP R6版本的PSS规范项目已经基本完成，在技术内容上与R5兼容。在协议、能力交换、网络适配、DRM等方面有所增强。在编解码方面，3GPP也根据相关组织规范的最新版本进行了更新，与之保持一致，并

且在R6引入了视频H.264(AVC)、音频Extended AMR-WB 和音频Enhanced aacPlus等几种编解码方式。

移动流媒体中的编码技术简介

肖民供稿：《广播电视信息》

2009年07月22日15:06 来源：人民网-传媒频道

【字号大中小】打印留言论坛网摘手机点评纠错

E-mail推荐:

提交

【摘要】流媒体技术是从互联网上发展起来的一种传送多媒体数据流的技术，其主要特点是以流的形式进行多媒体数据的传输。采用流媒体技术的客户端播放器在播放一个多媒体内容之前，预先下载媒体内容的一部分作为缓存，在将缓存中的这部分内容向用户播放的过程当中，该多媒体内容的剩余部分将在后台从服务器继续下载到客户端播放器上，这样就实现了所谓“边下载，边播放”的流式播放。

【关键词】流媒体H.264整数变换熵编码

流媒体技术是从互联网上发展起来的一种传送多媒体数据流的技术，其主要特点是以流的形式进行多媒体数据的传输。采用流媒体技术的客户端播放器在播放一个多媒体内容之前，预先下载媒体内容的一部分作为缓存，在将缓存中的这部分内容向用户播放的过程当中，该多媒体内容的剩余部分将在后台从服务器继续下载到客户端播放器上，这样就实现了所谓“边下载，边播放”的流式播放。

流媒体技术应用到移动网络和终端上，称之为移动流媒体技术。使用移动流媒体技术可以使用户通过智能手机、PDA等移动终端实时播放视音频等多媒体内容，也可以对多媒体内容进行点播，具有交互性。由于其具有灵活、方便以及可移动收看的特点，目前此类应用吸引了越来越多的用户。

由于目前移动运营商传输带宽的限制，为了支持更多用户的同时收看，要求传输的信号码流尽可能的低，因此目前此类应用中，对信源基本采用了压缩比最高的H.264的编码方式，下面主要介绍H.264的技术特点。

1 H.264 的制定过程

H.264 是由ITU-T 以及ISO／IEC两个组织联合组建的联合视频组（JVT）共同制定的数字视频编码标准，这一标准正式成为国际标准是 2003年3月在泰国举行的 JVT 第 7 次会议上通过的。由于该标准是由两个不同的组织共同制定的，因此有两个不同的名称：在 ITU-T 中，它的名字叫 H.264；而在 ISO／IEC 中，它被称为 MPEG-4 的第10 部分，即高级视频编码（AVC）。

2H.264 的技术特点

视频信号具有非常大的数据量，为了达到高效的压缩，必须充分利用各种冗余，一般来讲，视频序列里的冗余包括两类，一类是统计冗余，它包含：（1）频谱冗余，指色彩分量之间的相关性；（2）空间冗余；（3）时间冗余，这是视频压缩区别于静止图像压缩的根本点，视频压缩主要利用时间冗余来实现大的压缩比。第二类是视觉生理冗余，这是由于人类的视觉系统特性造成的，比如人眼对色彩分量的高频分量没有对亮度分量的高频分量敏感，对图像高频（即细节）处的噪声不敏感等。

针对这些冗余，视频压缩算法采用了不同的方法加以利用，但主要的考虑集中在空间冗余和时间冗余上。与以前的标准类似，H.264 也采用了所谓的混合结构，即对空间冗余和时间冗余分别进行处理。然而，以下介绍的技术使得 H.264比之前的视频编码标准在性能上有了很大的提高。应当指出的是，这个提高不是单靠某一项技术实现的，而是由各种不同技术带来的小的性能改进而共同产生的。

(1) 帧内预测

对 I 帧的编码是通过利用空间相关性而非时间相关性实现的。以前的标准只利用了一个宏块内部的相关性，而忽视了宏块之间的相关性，所以一般编码后的数据量较大。为了能进一步利用空间相关性，H.264 引入了帧内预测以提高压缩效率。简单地说，帧内预测编码就是用周围邻近的像素值来预测当前的像素值，然后对预测误差进行编码。这种预测是基于块的，对于亮度分量，块的大小可以在 16×16 和 4×4 之间选择，16×16 块有 4 种预测模式，4×4 块有 9 种预测模式；对于色度分量，预测是对整个 8×8 块进行的，有 4种预测模式。

(2) 帧间预测

与以往的标准一样，H.264 使用运动估计和运动补偿来消除时间冗余，但是它具有以下几个不同的特点：

1）预测时所用块的大小可变

由于基于块的运动模型假设块内的所有像素都做了相同的平移，在运动比较剧烈或者运动物体的边缘处这一假设会与实际出入较大，从而导致较大的预测误差，这时减小块的大小可以使假设在小的块中依然成立。另外小的块所造成的块效应相对也小，所以一般来说小

的块可以提高预测的效果。

为此，H.264一共采用了 7 种方式对一个宏块进行分割，每种方式下块的大小和形状都不相同，这就使编码器可以根据图像的内容选择最好的预测模式。与仅使用 16×16 块进行预测相比，使用不同大小和形状的块可以使码率节省 15％以上。

2）更精细的预测精度

在 H.264 中，亮度分量的运动矢量使用 1／4 像素精度。色度分量的运动矢量由亮度分量的运动矢量导出，由于色度分量分辨率是亮度分量的一半（对4:2:0），所以其运动矢量精度将为1／8，也就是说 1个单位的色度分量的运动矢量所代表的位移仅为色度分量取样点间距离的 1／8。如此精细的预测精度较之整数精度可以使码率节省超过 20％。

3）多参考帧

H.264 支持多参考帧预测，即可以有多于一个（最多 5个）的在当前帧之前解码的帧可以作为参考帧产生对当前帧的预测。这适用于视频序列中含有周期性运动的情况。采用这一技术，可以改善运动估计的性能，提高 H.264 解码器的错误恢复能力，但同时也增加了缓存的容量以及编解码器的复杂性。较之只使用一个参考帧，使用5 个参考帧可以节省码率5～10％。

4）抗块效应滤波器

它的作用是消除经反量化和反变换后重建图像中由于预测误差产生的块效应，即块边缘处的像素值跳变，从而既改善了图像的主观质量，也减少了预测误差。H.264 中的抗块效应

滤波器还能够根据图像内容做出判断，只对由于块效应产生的像素值跳变进行平滑，而对图像中物体边缘处的像素值的不连续给予保留，以免造成边缘模糊。与以往的抗块效应滤波器不同的是，经过滤波后的图像将根据需要放在缓存中用于帧间预测，而不是仅仅在输出重建图像时用来改善主观质量。需要注意的是，对于帧内预测，使用的是未经过滤波的重建图像。

（3）整数变换

H.264 对帧内或帧间预测的残差进行 DCT 变换编码。为了克服浮点运算带来的硬件设计复杂，更重要的是舍入误差造成的编码器和解码器之间不匹配的问题，新标准对 DCT 的定义做了修改，使得变换仅用整数加减法和移位操作即可实现，这样在不考虑量化影响的情况下，解码端的输出可以准确地恢复编码端的输入。当然这样做的代价是压缩性能的略微下降。此外，该变换是针对 4×4 块进行的，这也有助于减少块效应。

（4）熵编码

如果是 Slice 层预测残差，H.264 有两种熵编码的方式：基于上下文的自适应变长码和基于上下文的自适应二进制算术编码；如果不是预测残差，H.264 采用Exp-Golomb 码或基于上下文的自适应二进制算术编码，视编码器的设置而定。以上介绍的特点都是用来提高 H.264 的编码性能的，此外 H.264 还具有很好的错误恢复能力和网络适应性。

通过上面的介绍，毋庸置疑，H.264 在压缩性能上要比其他标准优越，在同等图像质量的条件下，H.264 的压缩比是 MPEG-2 的 2 倍以上，是 MPEG-4 的 1.5～2 倍。尤其值得一提的是，H.264 在具有高压缩比的同时还拥有高质量流畅的图像。

移动流媒体技术的应用开创了无线通信网络与互联网、视音频压缩编码技术相融合的新

时代，随着手机、PDA等移动终端产品功能的不断提升，移动流媒体技术必将带给人们更多、更好的音视频体验。

3G视频点播系统中流媒体协议栈的解决方案

2009/02/11

摘要随着宽带互联网技术的普及和多媒体技术在互联网上的应用，视频点播已经不再局限于有线网络，扩展到了3G移动领域。本文首先介绍一个3G视频点播系统，并在此平台上介绍了3G流媒体协议栈的概念、特点及其架构，然后针对该系统的整体框架详细论述了3G流媒体协议栈的模块实现，并讨论了各个功能模块的作用及相互之间的影响，最后详述了流媒体传输的关键环节——同步机制，从而在3G终端实现客户端\服务器式的流媒体数据的实时传输。

1、概述

1.1 3G视频点播系统概述

视频点播技术即VOD（VideoOnDemand），最初出现是缘于人们对广播电视的需求，但之前VOD一直局限于有线网络，从而无法给用户提供一个完全自主便捷的环境。在这样的情况下，无线移动视频点播业务的出现提供了一个可以和外界交流的平台。3G技术的成熟，更是为这项业务提供了一个可靠的实现基础，人们在任何时间，任何地点，只要通过一部3G手机，就可以像在家通过电视或电脑连接上有线网络一样的在整个网络环境中随意浏览任何自己感兴趣的节目，从而提供给人们一个交互式的主控权利，随机随时的获取网络资源。在3G视频点播系统中，手机客户端接受来自基站服务器发送的媒体数据，经过一系列的处理呈现给用户播放的图像，服务器接收客户端返回的质量报告进行分析，并根据网络的实际状况给出合适的传输方式以及合适的图像编码格式，进行流量控制。客户端完全是被动的数据处理，媒体数据解码，视频和音频的同步。而服务器则承担了大部分的网络质量状况监测任务。这个方式有点类似于HTTP方式下的客户机/服务器模式。而上述这种实时流媒体传输的运行架构则需要完善可靠的流媒体协议栈来支持。

本文即介绍一个3G视频点播系统（如图1所示）中流媒体协议栈的实现，该系统由3部分组成：服务器，Internet和手持设备，针对该系统，本文首先介绍了实时流媒体协议栈的概念、特点及其发展背景，然后在此基础上讨论了实时流媒体协议栈在此3G 视频点播系统中的软件架构，最后详细论述各个模块的设计及流媒体传输的关键环节——同步机制。

图1 系统概述图

1.2 系统平台

系统工作的硬件平台、软件平台如下：

硬件平台：SH-mobilesolutionincludesaSH3-DSPcoreMCU，memory，IO，and LCD etc，Abase-band controller（AT91 RM9200 Base-Band board），一台服务器（即PC机）。

软件平台：SH-7300实时操作系统（Norti4），

MPEG-4audio/videoencoder/decodermiddleware，流媒体协议栈（如图2所示）。

图2 系统软件平台

2、基于3G终端的流媒体协议栈的架构

2.1 流媒体协议栈及其特点

以3G协议栈为基础的实时流媒体协议栈（real-timestreamingmediaProtocols）

具有强大的兼容性，能根据基站服务器通信准则建立最优播放效果，并根据网络状况，实时适应以改变通信策略和媒体播放效果。协议栈将可以保证以下业务：

（1）进行视频通话，三方举行视频会议；

（2）替代以电视为媒体的广告与节目播放，提供更具吸引力的多媒体点播等互动服务；

（3）享受移动银行，股票信息，以及电子交易等各种信息服务。

实时流媒体协议栈可以设计为一个与系统无关的模块，以实现在目前3种3G标准WCDMA、cdma2000、TD-SCDMA之上无缝移植和嵌入。我们以协议为指导，根据无线移动网络的实际情况，做出合适的裁减和改变。流传输控制机制将根据3G网络的特性和嵌入式实时系统的要求定制，使协议栈能够发挥可靠的，高效率的作用。同时协议栈不仅提供标准的应用程序接口，还可以根据客户的要求特别定制专用的应用程序接口。

2.2 流媒体协议栈整体架构

基于3G终端的流媒体协议栈由RTSP协议栈，RTP/RTCP协议栈，TCP/IP协议栈组成。

2.2.1 TCP/IP协议栈

TCP/IP协议栈是由3G的协议栈提供，负责对流媒体数据的传送。TCP、UDP的协议都将使用到，并且根据不同的网络情况，分别使用。TCP是用于可靠的连接，RTSP协议将尽量使用这个协议进行传输，UDP是无连接的协议，RTP/RTCP协议栈将通过这个协议传送数据。当然这也不是绝对的，在必要的时候，RTSP可以使用UDP协议，比如防火墙的强制隔离，要求代理服务器转发，这时需要由协议栈来保障RTSP协议的可靠性，包括使用重发机制；RTP/RTCP也可以使用TCP连接，比如要求跨防火墙，建立直接连接的通道，这时可能牵涉到RTSP和RTP/RTCP协议的算法，需要由协议栈来提供。

2.2.2 RTP/RTCP协议栈

RTP/RTCP协议是流媒体协议栈中关键的一部分，它承担了媒体数据的传送，由2

个相互紧凑的协议组成，数据报文实时传输使用的RTP协议和QoS监视的RTCP协议。协议设计者并不考虑RTP协议的纠错功能，而要求下层协议来保证，以提高媒体帧传输的数量，节省带宽，节省程序的开销，其传输机制专注于媒体本身的可靠性传输。RTP 直接面向媒体数据，是一种以带宽和网络质量为先决条件的传输协议，其传输方式是随着带宽和网络质量变化而动态调整的协议，其宗旨是以最大的可能性利用网络的负载能力，确保大容量的多媒体数据能及时的传输。在这样的设计思想下，3G信道带宽不至于

过度浪费，因此适合于手机终端的使用。同时，RTCP协议作为传输控制协议，也是网络质量的监测者，它为互动的双方提供了统计意义上的报告，为双方提供网络实际的质量，也为流量控制，编码方式，提供了可靠的保证和参考。作为独立于3G协议栈的应用层媒体协议栈，RTCP根据其机制，提供质量服务QoS，为网络运营商监视网络情况提供参数。

2.2.3 RTSP协议栈

RTSP协议栈是流媒体协议栈中与界面和RTP/RTCP协议相关的控制协商操作。RTSP 提供响应界面操作的接口，直接响应界面发送的命令。同时RTSP也提供互联的双方或多方的一个传输方式和编码方式的协商操作，在网络允许情况下，建立一条最佳传输通道。以最匹配的情况传输数据，而无须每次传输都要求双方解析，节省了大量的时间，也减少了出错的可能性。

RTSP和RTP/RTCP协议栈组成整个流媒体协议栈的核心部分，他们各自的控制机制是需要根据无线移动网络的实际情况和媒体编码格式统筹设计，在协议中是没有硬性规定的。

3、3G视频点播系统中流媒体协议栈的模块设计

系统的模块化有利于整体功能的实现，本系统框架从流媒体协议栈进行规划，分为5个模块：人机界面、RTSP模块、RTP/RTCP模块，以及硬件媒体编解码器模块。模块架构如图3所示。

图3 视频点播系统架构

3.1 人机界面（MMI）

界面部分是手机终端提供给用户的交互界面。用户可以使用它来控制播放的动作，比如通过点击Web的链接，接入流媒体服务器。可以进行播放、暂停、终止、快进、后退等操作，当然，所有操作是在服务允许的范围，超出服务范围的操作将被禁止。通过界面，用户就可以享受到视频/音频的多媒体服务，可以点播电影，也可以召开会议。

3.2 RTSP模块

RTSP模块是以客户端为主的应用控制模块，以适应3G手机终端对媒体点播的需要。主要内容包括：RTSP协议栈的会话的建立、会话的传输、会话的协商和会话的终止，以及文本指令的解析。在流媒体协议栈架构中，RTSP处于TCP/IP层之上，使用TCP协议传输会话数据。处于界面控制程序直接操作下，为应用界面提供编程接口。同时RTSP 对媒体数据层和RTP协议有着控制的权利，可以调整RTP会话参数，以及媒体层同步等等。RTSP是一个类似HTTP的服务器-客户端的模型，但与HTTP不同的是双方都可发送请求并都可以响应请求，是一个对等互动的协商协议。

在此视频点播系统中，RTSP模块通过TCP协议的三次握手机制来保证命令消息通道的可靠性。一方面接收服务器的确认信息传给应用层进行处理；另一方面接收来自客户端的命令信息，解析后反馈给服务器。此外，RTSP模块支持以下操作：

（1）从媒体服务器端获取媒体。客户端能够通过HTTP或者其它模式来请求一个的图像描述。如果图像正被多点传输，那么图像描述就包含了用来传输连续媒体多点传输的地址和端口。如果图像只能被单点传送，那客户端就要因为安全原因而提供给目的地址。

（2）邀请媒体服务器参加会议。一个媒体服务器端能够被“邀请”参加一个存在的会议，可以回放媒体成为图像，或者记录图像中的媒体的全部或者一部分。

（3）在存在图像中增加媒体。尤其对于活动图像，如果服务器能告诉客户端，增加的媒体是有用的。

3.3 RTP/RTCP模块

RTP/RTCP模块是以客户端为主的应用传输模块。主要内容包括：RTP/RTCP协议栈的会话的建立，会话的传输，会话的控制和会话的终止。此模块位于TCP/IP层之上，使用UDP协议传输数据。当应用程序开始一个RTP会话时通常使用两个端口：一个给RTP，一个给RTCP。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送

的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP的媒体数据载荷加载准则依赖于不同的媒体编码格式而不同，数据报文的格式按照RFC规定的实现。

同时应用程序可以通过此模块调整传输频率去和接受者的能力相匹配，或者以适应网络拥塞。通过参加多点传送组的适当的子集，接受者能适应不同的网络并控制他们的接受带宽。此外模块中所有的多媒体会话，都将视频和音频分别存放，这是为了保证在与某些不具有视频功能的终端通信或者在网络质量恶劣的情况下，可以只提供音频服务，而将视频服务关闭。

3.4 硬件媒体编解码模块

硬件媒体编解码器是基于MPEG-4实现的硬件Codec，采集的视频音频原始数据通过它压缩后形成MP4的数据格式，通过传输协议发往服务器；来自服务器的MP4视频音频数据通过Codec还原为原始数据，送往终端显示器，提供用户动态界面。当然画面可能因为压缩和传输的损伤有所下降，针对这样的情况，协议栈将提供纠错，补偿，同步功能来修复损伤，力图保持最完美的视频语音效果。

4、流媒体同步机制

流媒体数据和传统数据的一个主要不同是不同媒体流的集成，主要表现为同步方式。在3G视频点播系统中，流媒体传输的同步机制是一个非常关键的问题，同步机制设计

的好坏直接涉及到了播放效果，而播放效果则是直接面向用户，是检验媒体播放质量的直接证据。

媒体同步定义是不同媒体流之间以及数据流内的基于时间的关系。目前有3层同步，分别是系统同步（流内同步）、媒体间同步（流间同步）和用户层同步（目标间同步）。

媒体数据的同步丢失是由于从服务器发往客户端的媒体数据报文因为不同的路由

路径导致，而且所有媒体数据的存储转发都将产生延迟和抖动。延迟以及延迟的可变性将导致以上3种同步的丢失。因此，媒体间同步机制是必须的，以确保在客户端正确的播放媒体数据。

4.1 系统同步（流内同步）

系统同步（流内同步）是底层同步。连续媒体或者时间相关的数据（比如，视频和音频）的媒体层同步是最底一层。媒体层的最小单位是逻辑数据单位（LDU），比如视

频和音频帧，需要严格的按照时间顺序以确保用户可以精确的回放。系统同步缺失将导致播放暂停或跳跃。

本文来源：https://www.bwwdw.com/article/85rl.html