rtsp协议十篇
时间：2023-04-10 23:41:46
rtsp协议篇1
关键词： Darwin Streaming Server；流媒体；RTSP；直播
中图分类号：TP311.52 文献标识码：A 文章编号：1671－7597（2012）0310040－01
0 引言
随着网络技术和流媒体技术的发展，流媒体技术的出现给互联网带来勃勃生机。为了在网上听歌或者看一部电影，人们不需要再等待漫长的下载过程，可以直接尽情的享受其中的乐趣。
Darwin Streaming Server简称DSS。DSS是Apple公司提供的开源实时流媒体播放服务器程序。整个程序使用C++编写，在设计上遵循高性能，简单，模块化等程序设计原则，务求做到程序高效，可扩充性好。并且DSS是一个开放源代码的，基于标准的流媒体服务器，可以运行在Windows NT和Windows 2000，以及几个UNIX实现上，包括Mac OS X，Linux，FreeBSD，和Solaris操作系统上的。
1 使用VLC作为视频流接受生成SDP方法实现直播
1.1 采集端（Windows操作系统）
使用本公司开发的QN_AMCAP通过电脑USB接口摄像头，获取视频信息，编码之后，通过RTP的方式发送给darwin流媒体服务器。也可以使用VLC直接获取USB接口摄像头视频信息，然后再进行编码发送。VLC支持发送的协议有：HTTP，MS-WMSP（MMSH），RTSP，RTP，UDP等协议，通过这些协议都可以使用VLC将视频流信息发送到目的地。下面是几种协议VLC使用的发送命令：
1）HTTP协议的发送命令是：
:Sout=#transcode{vcodec=h264,vb=800,scale=1,acodec=mp4a,ab=128,channels=2,samplerate=44100}:http{mux=ts,dst=:8080/}:no-sout-rtp-sap :no-sout-standard-sap :sout-all :ttl=1 :sout-keep
2）MS-WMSP（MMSH）协议的发送命令是：
:sout=#transcode{vcodec=h264,vb=800,scale=1,acodec=mp4a,ab=128,channels=2,samplerate=44100}:std{access=mmsh,mux=asfh,dst=0.0.0.0:8080}:no-sout-rtp-sap :no-sout-standard-sap :sout-all :ttl=1 :sout-keep
3）RTSP协议的发送命令是：
:sout=#transcode{vcodec=h264,vb=800,scale=1,acodec=mp4a,ab=128,channels=2,samplerate=44100}:rtp{sdp=rtsp://:5544/}:no-sout-rtp-sap :no-sout-standard-sap :sout-all :ttl=1 :sout-keep
4）RTP协议的发送命令是：
:sout=#transcode{vcodec=h264,vb=800,scale=1,acodec=mp4a,ab=128,channels=2,samplerate=44100}:no-sout-rtp-sap :no-sout-standard-sap :sout-all :ttl=1 :sout-keep
1.2 Darwin服务器端（windows\linux系统）
使用VLC接收采集端发送到darwin服务器端的视频流，并且在darwin安装目录先的Moves目录下生成SDP文件。Darwin服务器通过SDP文件获得需要的视频播放信息，将视频流转换为RTSP流，其他的客户端便可通过RTSP协议播放直播内容。
2 使用darwin的relay中继功能实现直播
2.1 Darwin设置中继
使用三台windows的PC，一台（命名为A，IP地址为192.168.1.2）作为源server，一台（命名为B，IP地址为192.168.1.3）做relay服务器，一台（命名为C，IP地址为192.168.1.4）作为客户端。在A机上使用VLC或其他RTSP源，A机将本机上获取到的直播视频信息发送给B机，然后C机就能够通过访问B机来播放A机的媒体文件，也就是通过VLC或其他RTSP源，darwin流媒体服务器实现了视频直播。
2.2 VLC或其他RTSP源发送RTSP流
A机也就是源server，不需要使用darwin服务器，而是使用VLC获取USB接口摄像头视频信息，然后通过RTSP协议发送给B机。需要配置的darwin服务器为B机。
配置步骤：
1）B机安装perl和Darwin Streaming Server，C机安装VLC播放器。
2）在A机中使用VLC开始发送RTSP流。
2.3 Darwin流媒体服务器通过中继功能接收RTSP流
Darwin流媒体服务器可以通过中继功能接收VLC或其他RTSP源发送过来的RTSP流，然后实现直播功能。
下面是实现的步骤：
1）将A机VLC生成的SDP文件（v.sdp文件）拷贝到B机的媒体文件夹中。在B机上编辑v.sdp文件，找到第一个以“m=”开头的行，将0改为前面在Relay Setting中配置的Base Port（i.e.20000）；继续找到下一个以“m=”开头的行，将0改为Base Port+2（i.e.20002）。
2）B机打开浏览器键入192.168.1.3:1220，输入用户名和密码。
3）在B机建立新的relay。单击左侧relay Settings，在右侧选择New Relay。
① Source Settings中：
Source Hostname or IP Address中填写源数据IP。因为是接收A机VLC或其他RTSP视频源发送过来的直播RTSP流，所以，Source Hostname or IP Address中填写的是A机的IP地址：192.168.1.2。
Mount Point就填写要播放的直播RTSP流的名字（/v.sdp）。
Request incoming Stream中填写A机的DSS用户名和密码。
② Destination Settings中：
Hostname or IP Address填写目的IP地址。因为是接收A机发送过来的直播视频流，所以，Source Hostname or IP Address中填写的是127.0.0.1。
Base Port中填写将送达B机的端口号（这个需要在VLC或其他RTSP源发送RTSP流的时候进行设置）。
Multicast TTL填写最多可以中继的级数。
在页面最下方有save changes保存设置。
4）启动C机的VLC，打开url：rtsp://192.168.1.3/v.sdp。
5）C机播放了A机发出的直播视频。
3 结语
本文对通过苹果开源项目Darwin Streaming Server作为流媒体服务器来实现流媒体直播方案相关讨论，通过对Darwin服务器的设置方法和配置，来实现了两种流媒体的直播方案。
参考文献：
rtsp协议篇2
【关键词】流媒体 启动延时 RTP
自互联网产生以来，受网络带宽的限制，互联网上的信息都以文字、图片等静态数据为主，而音频、视频数据则难以在网上。随着ADSL、视迅宽带、FDDI网的出现，网络带宽得到很大的改善，可以达到100M以上的传输速率，但仍无法满足高质量的多媒体信息传输的需要，这就要从数据的传输方式上着手来解决问题。由此，流媒体技
术应运而生。
一、流媒体技术概述
流媒体（Streaming）技术是指在发送端和接收端之间以独立于网络负载的以给定速率传输音频、视频信息的一种传输技术。流媒体具有隐含的时间维、传输的实时性和等时性、高吞吐量等特点。目前因特网由于存在带宽不足、服务质量控制机制较弱等局限性，难以满足流媒体的实时性要求，为此因特网工程任务组（IETF）制定了一系列支持流媒体实时传输和服务质量控制的协议，如 RTP、RSVP、RTCP等。其中，RTP是所有这些协议的基础。在网络上传输音频或视频等多媒体信息，目前主要有下载回放和流式传输两种方案。下载回放方式时间长、占的内存多，要求用户等到整个文件全部下载完毕才能回放。流式传输中声音、影像等通过网络向用户计算机进行连续、实时传送，用户不必等到整个文件全部下载完毕，而只需经过几秒或十几秒的启动延时即可进行观看。
流媒体技术是一种使用流式传输连续的时基媒体的技术。流式传输方式是将视频、音频等其他媒体压缩为一个个压缩包，由视频服务器向用户计算机连续、实时传送，只需要在用户端缓存足够可播放的视频容量就可以开始播放。
二、流媒体系统的组成
1、编码工具。即用于创建、捕捉和编辑多媒体数据，形成流媒体格式。利用媒体采集设备进行流媒体的制作。它包括了一系列的工具，从独立的视频、声音、图片、文字组合到制作丰富的流媒体。这些工具产生的流媒体文件可以存储为固定的格式，供服务器使用。
2、流媒体数据。即媒体信息的载体。常用流媒体数据格式有.ASF、.RM等。
3、服务器。即存放媒体数据。由于要存储大容量的影视资料，因此该系统必须配备大容量的磁盘阵列，具有高性能的数据读写能力，可以高速传输外界请求数据并具有高度的可扩展性、兼容性，支持标准的接口。这种系统配置能满足上千小时的视频数据存储，实现片源的海量存储。
4、网络。即适合多媒体传输协议甚至是实时传输协议的网络。流媒体技术是随着互联网络技术的发展而发展起来，它在现有互联网络的基础上增加了多媒体服务平台。
5、播放器。即供用户欣赏网上媒体的软件。流式媒体系纺支持实时音频和视频直播和点播，可以嵌入到流行的浏览器中，可播放多种流行的媒体格式，支持流媒体中的多种媒体形式，如文本、图片、Web页面、音频和视频等集成表现形式。在带宽充裕时，流式媒体播放器可以自动侦测视频服务器的连接状态，选用更适合的视频以获得更好的效果。目前应用最多的播放器有美国Real Networks公司的Real Player、美国微软公司的Media Player、美国苹果公司的Quicktime三种产品。
目前，Real System 被认为是在窄带网上最优秀的流媒体传输系统，其允许的带宽限制从28.8kbps的拨号上网到10M 的局域网，允许点播的人数从 100 流到 1000 流甚至无限流。Real System 系统由三部分组成。一是媒体内容制作工具Real Producer。主要是用于压缩制作多媒体内容文件，实时压制现场信号并传送给Real Server进行现场直播；也可以把其他音频、视频和动画等多媒体文件格式转换成Real Server支持并进行流媒体广播的 Real格式。二是服务器引擎 Real Server。它是目前国际上最强力的因特网和Intranet上的流传播服务引擎，利用该服务引擎用户可以在客户端无须等待数据全部下载完毕即可实时收看直播节目。三是客户端播放软件 Real Player。用来向服务器发出请求，接收并回放从 Real Server传送的媒体节目。
三、流式传输协议
流媒体协议是流媒体技术的一个重要组成部分，也是基础组成部分。因特网工程任务组的主要工作是设计各种协议来规范与发展世界标准化组织，现已设计出几种支持流媒体的传输协议。
1、RSVP（资源预留协议）。该协议促使流数据的接收者主动请求数据流路径上的路由器，并为该数据流保留一定的资源（即带宽），从而保证一定的服务质量。RSVP是一个在IP上承载的信令协议，它允许路由器网络任何一端上终端系统或主机在彼此之间建立保留带宽路径，为网络上的数据传输预定和保证服务质量。
（1）RSVP协议中涉及到发送者和接收者的概念，这两个概念是在逻辑上进行区分的。发送者指发送路径消息的进程，而接收者是指发送预留消息的进程，同一个进程可以同时发送这两种消息，因此既可以是发送者也可以是接收者。
（2）资源预留的分类。专用预留：它所要求的预留资源只用于一个发送者，即在同一会话中的不同发送者分别占用不同的预留资源。共享预留：它所要求的预留资源用于一个或多个发送者，即在同一会话中的多个发送者共享预留资源。
（3）RSVP提供两种发送者选择方式。通配符方式：默认所有发送者，并通过预留消息中所携带的源端地址列表来限制通配符滤波器。显式指定方式：滤波器明确指定一个或多个发送者来进行预留。
2、RTP（实时传输协议）。用于Internet上针对多媒体数据流的传输。RTP协议为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在UDP上运行RTP以便使用其多路结点和校验服务。RTP可以与其他适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么RTP可以使用该组播表传输数据到多个目的地。
3、RTCP（实时传输控制协议）。实现通过客户端对服务器上的音视频流做播放、录制等操作请求。该协议通过RTSP协议实现了在客户端应用程序中对流式多媒体内容的播放、暂停、快进、录制和定位等操作。RTP和RTCP一起提供流量控制和拥塞控制服务。
4、RTSP（实时流协议）。建立并控制一个或几个时间同步的连续流媒体，如音频和视频。尽管连续媒体流与控制流交叉是可能的，但RTSP 本身并不发送连续流，换言之，RTSP充当多媒体服务器的网络远程控制。RTSP 提供了一个可扩展框架，实现实时数据（如音频与视频）的受控、按需传送。数据源包括实况数据与存储的剪辑。RTSP 用于控制多个数据发送会话，提供了选择发送通道（如UDP、组播UDP与TCP等）的方式，并提供了选择基于RTP的发送机制的方法。
总之，随着流媒体技术的不断发展以及网民对流媒体的需求的增加，流媒体技术将会日臻成熟并稳步发展。
参考文献
[1] 肖金秀、蔡均涛：多媒体技术及应用[M].冶金工业出版社，2006．
[2] 郑丽娜：网络流媒体技术及其应用[J].山东通信技术，2005（2）．
rtsp协议篇3
【关键词】IPTV;单播;多播 ;IGMP协议;TSP协议
引言
众所周知，IPTV是广播电视领域和电信领域的结合。IPTV系统与传统的单向广播电视系统相比较，在交互性应用上有着许多区别。IP网络的双向特性使用户通过网络实现视频点播（VoD）和网络数字视频录像（NDRV）成为可能，这两项服务也正是IPTV系统胜过单向广播电视系统的两个最常见的应用实例。因为在传统的单向广播电视系统中，播放的节目是由运营商向节目的收看者推出而不是由收看者按照自己的需求索取的。
一、工作原理
在标准的广播电视系统中，所有正常播出的频道（例如CCTV、JXTV 等等）一起发送到用户的机顶盒中（通过有线网络、卫星网络或地面传输系统）。所发送的频道可能有数百个，然而，这数百个频道是同时交付的。用户对机顶盒进行调谐以接收他选择的频道，以这种方式响应由收看者的遥控器发出的请求。因此，这种调谐频道的方式实际上是在收看者本地进行的，它使得频道的转换几乎是在瞬间完成的。
但是在IPTV系统中，为了充分利用预留给家庭用户的最终连接带宽，在设计IPTV系统时就考虑到仅将用户请求的节目频道而不是将所有频道传送到机顶盒。需要注意的是，有时也有可能将数个节目（或者频道）传送到同一家庭用户中的不同IP地址处，例如该家庭用户拥有几个单独的机顶盒或者拥有不同IP地址的其它接收设备。
在IPTV系统中，为了切换频道，需要将一个特定的指令发送到接入网络中以响应用户切换频道的请求。与这种频道转换技术相联系的是复杂的协议交换过程，在这一过程中要使用IGMP协议的“Leave”（离开）和“Join”（加入）指令。完成这种协议的交换需要一定的时间，而所需要的时间又受到网络中传输延时的显著影响;反之，协议的交换时间又会直接影响到系统的频道转换需要一定的时间。从本质上来说，在IPTV系统中，频道的转换是在网络中实现的而不是在本地机顶盒中完成的。因此，我们电视工作者在为终端用户保留这种宝贵的最后一公里的信号传输带宽的同时，这种频道转换方式也给IPTV系统的可分级性和可用性带来了一系列的复杂问题。
在IPTV系统中，以广播方式传送的电视节目是使用IP多播方式（它也属于IGMP协议，如前所述）经由IP系统以有效地传送节目。设计这种多播方式正是为了使许多网络用户共享这一会话。
但在IPTV系统的VoD业务中，采用的却是单播IP服务，它使用的是RTSP控制机制。每当收看者发出请求时，被选择的节目由网络中的服务器以独特的单播方式将节目提交给用户。这种收看方式从效果上来看，相当于在网络服务器与观看者机顶盒之间建立了一种专用的网络连接。
二、技术概述
（一） 视频压缩技术
在IPTV的早期阶段，采用的是MPEG-2压缩系统。在IP网络中传送一路标准清晰度的视频信号，如果采用MPEG-2编码，大约需要3.75Mbps的带宽，如果传送一路高清晰度视频信号，则需要12至15Mbps的带宽。这样说来，为了给家庭用户提供两个频道的SD编码的电视信号，大约需要8Mbps带宽。如果在接入到家庭的网络采用的是xDSL接入技术，那么容易看出，这种接入网络的传输带宽将是一个问题。为了减少对接入网络的带宽需求，一种方法是采用新的视频压缩技术，例如H.264或者VC-1编码技术。采用H.264编码，在获得同样图像质量的前提下，可以比现在使用的MPEG-2压缩编码节约50%的带宽利用率。在IPTV系统中选择什么样的压缩编码技术，带宽是一个重要因素。然而，还必须考虑许多其它因素。采用MPEG-2编码，平均图像组的长度，即GOP的长度，或者说两个相邻I帧之间的图像组长度大约为12至18帧。如果采用H.264编码，GOP的长度可能有300帧。这就是说，用H.264编码的视频流将对包丢失更加敏感，因为每一H.264编码帧均包含有更多的有效图像信息（这是因为它们采用了更高效的图像压缩率），因此，H.264编码帧的丢失对用户观看体验质量的影响会更加显著。除了上述技术上的理由之外，还有其它一些因素也应当考虑。例如编码器和接收机（机顶盒）在商业上的可用性问题，以及H.264编码设备与其它网络部件的互操作性问题等。
（二） 网络协议
IPTV系统中有一些常用的协议，这些协议包括IP传输协议，例如UDP和RTP，以及一些信令协议，例如RTSP和IGMP等。尽管在本文中提到这些协议，但是实际上，IPTV系统涉及到协议远不止这几个。在现代网络系统中还要用到许多协议，例如MPLS、SIP和SIM如此等等。但这些内容已经超出了这篇文章的范围。
1. UDP或用户数据报协议
UDP是在IETF RFC 768文档中定义的一个协议，它是IP协议簇中的一个重要协议。“数据报”或者“分组”、“包”这些术语是用来描述一个IP数据块。每个IP数据报均包含有特定的字段组，而且所有的这些字段在各个分组中均有着特定的排列顺序，这样当目的端接收到这些分组时就知道如何解码这种数据流。许多协议分组可以被封装在IP数据报的有效负载中。
2.RTP或实时传输协议
RTP是在IETF RFC 3550文档和IETF RFC 3551文档中被定义，它是基于包的格式以传送音频数据和视频数据。RTP实际上是由两个紧密相关的部分组成的：RTP和RTCP。实时传输协议RTP：RTP提供了时间标记、包顺序号，以及和其它传输机制一起以解决传输定时问题。通过这样的机制，RTP提供了网络中端到端的实时数据传输。利用包顺序编号也可以识别包的丢失或者识别那些传输顺序发生错误的数据包（无序包）。实时传输控制协议RTCP：该协议用来获取端到端监视数据、数据的交付信息以及QoS等。
3. RTSP或实时流协议
RTSP是在IETF RFC 2326文档中被定义，它用来描述对流媒体实现类似于VCR操作的控制功能。实时流协议的典型应用是从客户端向服务器端发送RTSP信息，尽管有时也有例外，即由服务器端向客户端发送RTSP信息。在IPTV系统中，RTSP用于VoD应用服务中，即网络用户（客户端）利用实时流协议访问并控制保存在VoD服务器中的内容。VoD基本上是一对一的通信连接，它建立在单播应用的基础上。单播方式与广播方式恰恰相反。在广播方式中，我们将信息发向网络中的所有用户;单播则允许服务器端接受单个用户的请求而为其提供VoD 服务，并将用户所要求的信息或内容发送给单个用户。
4. IGMP或网际组管理协议
IGMP由几个IETF RFC文档所定义，最新的版本由RFC 3376所定义。IP组播被定义为将一个IP数据报传送给一个“主机组”。这个主机组是用一单个IP目的地址识别的一组主机。在IPTV系统中，主机组可以是希望接收一个特定节目的一组网络用户。
三、广电优势
与电信行业等其他行业相比，广电行业在IPTV的发展上有着其他行业所不能比拟的得天独厚的优势，具体表现在：
（一）内容优势：IPTV作为一种以视频互动点播为基础的业务形态，对内容资源的消耗巨大，必须要有一个丰富、强大的资源库作为其业务的供应点，否则将是“无源之水”。而广电系统经过数十年来的发展，除了拥有现在的丰富的内容资源外，还拥有最强大的制作团队与硬件资源，无论是历史还是新制作的节目资源，广电都拥有得天独厚的优势。
（二）网络优势：IPTV作为一种在局域网上运营的业务模式，有线电视网络双向化改造以后非常适合IPTV的发展。因为有线电视网络的稳定、可靠、可管理及高带宽可为IPTV业务的传送提供充分保障。
（三）政策优势：国家已经明确IPTV是一种媒体，而广电部门具有媒体运营的丰富经验，由现有的媒体运营机构运营IPTV等新媒体业务不存在政策风险。
四、术语介绍
IPTV：交互式网络电视，是一种利用宽带网，集互联网、多媒体、通讯等技术于一体，向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术。
单播：发送信息由一个源地址指向另外一个目的地址。
多播：将信息同时提交给的一组目的端地址。
视频点播（VoD）：在视频点播系统中，电视节目或电影节目可以在被某一单个用户请求时而发送给该用户。
参考文献：
rtsp协议篇4
移动流媒体技术就是把连续的声音影像信息经过压缩处理后传送到网络服务器上，让终端用户能够在下载的同时观看收听，而不需要等到全部的多媒体文件下载完成就可以即时观看的技术。移动流媒体技术的出现是伴随这移动通信技术的发展和网络音视频技术的进步，其只要是关于流媒体数据从采集到播放整个过程中所需要的核心技术。流媒体播放技术有优点也有缺点。优点是能够及时传送随时播放，缺点是由于网络的速率不稳定性，当播放速率大于传输速率时，视频播放将出现停滞，时断时续的现象。
2 Android的视频监控系统
基于Android的视频监控系统分为五个模块：依次为采集模块、编码模块、视频传输模块、解码模块、显示模块，下面分别进行详细介绍。
2.1 视频采集模块
Android摄像头采集到的视频格式为YUV420格式的视频流。采集模块的实现可以在Android的应用层中通过编写代码来实现。
2.2 编码模块
数字视频编码标准主要由两个标准化组织制定。MPEG制定的视频编码标准有MPEG-1，MPEG-2，MPEG-4。ITU一T制定的视频编码标准有H.261和H.263。为了促进下一代多媒体通信的应用， MPEG和VCEG共同成立了联合视频工作组（JVT），共同开发了视频编码标准H.264。H.264是目前最先进的视频编码标准。
H.264视频编码标准是目前最新的技术，虽然H.264遵循了原来压缩标准的架构，但是H.264具有一些新的特性，H.264标准分两层结构，包含网络抽象层（NAL）和视频编码层（VCL）。网络抽象层用于数据打包和传输，编码层负责视频压缩编码，这种分层结构，实现了传输和编码的分离。由于H.264标准引入了数据分割等抗误码技术，实现了在复杂环境下的使用，可以适应不同网络的传输要求。由于采用高度复杂的实现算法，H.264是目前低码率下压缩率最高的编码标准，在带宽不稳定的无线网络上有着无法比拟的优点。
2.3 传输模块
流媒体传输和控制协议在应用层主要涉及到HTTP，RTSP，RTP和RTCP协议，在传输层有TCP和UDP协议。HTTP是建立在传输控制协议（TCP）之上的超文本传输协议。TCP/IP协议是专为数据传输而设计的，能够保证传输的可靠性。RTP是在一对一或一对多的情况下针对流媒体数据流工作，不仅能够提供时间信息而且可以保证数据流的同步。通常RTP建立在UDP之上，使用UDP传输数据。RTP本身没有可靠的传送机制，其流量控制和拥塞控制是由实时传输协议（RTCP）来提供的。RTP和RTCP共同协作才能完成流媒体的传输和控制。实时流协议（RTCP）是应用层协议，位于RTP和RTCP协议层之上，通过IP网络传输多媒体数据，在传输机制上采用TCP和RTP完成数据传输。RTSP用于控制实时数据的发送，提供用于音视频流的VCR远程控制功能和用于控制流媒体的播放、暂停、记录等操作。会话描述协议SDP，SDP是用来描述RTSP，以便说明一个流媒体会话的基本属性。结合移动视频监控系统对通信实现的特点，本文采用RTP，RTSP，RTCP和HTTP协议完成视频监控系统的通信和远程控制。
一个最基本的流媒体系统包括编码器，流媒体服务器和客户端播放器三个部分。各个模块之间的数据通信交换都是按照特定的协议。编码器用来将原始的音视频转换成合适的流媒体格式文件，服务器用来接收和转发编码后的媒体流，客户端则是负责解码和播放接收到的流媒体数据。流媒体传输有两种方式，一种是顺序流式传输，一种是实时流式传输。
（1）顺序流式传输。顺序流式传输就是顺序下载。用顺序流式传输方法基于标准HTTP或FTP服务器来传输文件，通常容易管理，方便用户的使用。整个下载过程是无损的，能够保证视频的高质量，但是用于网络传输速率的问题，一般需要等待较久的时间。顺序流式传输常用于对视频质量要求较高的场合，对实时性，随机访问性要求较高的场合则不适用。
（2）实时流式传输。实时流式传输能够保证信号带宽与网络连接的匹配，实现实时传送，适合现场直播，支持随机访问，用户可进行快进后退操作。实时流式传输需要传输网络协议和专用的流媒体服务器。由于这些协议与防火墙有关，在使用时一需经过配置。系统设置，管理比顺序流式传输复杂。由于必须匹配连接带宽，在低速连接设备时或者网络拥塞时，会出现丢帧现象，导致视频质量下降。
2.4 解码模块
解码从性质来来讲，其实是编码过程的逆过程。编码采用H.264进行编码，所以该模块也采用H.264进行解码。解码器的整体设计可以分成两部分，一部分是视频数据的解码部分，主要用C语言来实现，采用Android NDK+C的实现机制。另外，一部分是视频的显示部分，主要采用Android提供的组件来实现，采用Android SDK+Java的实现机制。而这两部分的集合，则是通过java提供的jni机制来实现Java和C语言之间的通信。整个解码流程可分为三个功能模块：前段码流处理、H.264解码和后段视频显示。
（1）前段码流处理：主要负责文件的读取，从码流中分隔出NAL然后交给底层进行解码处理。
（2）H.264解码：整个解码的核心部分，通过本地C语言的实现和解码库对码流数据进行处理，完成H.264解码实现图像重建。
（3）后端视频显示：接收H.264解码模块解码后的视频数据，在客户端进行显示。
通过分析三个模块的功能可知，H.264解码模块是最耗费资源的。H.264视频标准为了更好的适应网络传输的特性，采用了分层设计的思想既视频编码层VCL和网络提取层NAL。
2.5 显示模块
通过调用Android自带的显示器，来显示解码后的本地数据流，从而达到实时视频的显示效果。
3 结束语
本文介绍了移动流媒体技术的概念及特点，考虑到网络速率的不稳定性带来的一些列影响，设计了一个基于Android的视频监控系统，系统分为五个模块，依次为采集模块、编码模块、视频传输模块、解码模块、显示模块，这种系统很好地解决了视频监控系统的安全性、实时性和稳定性等要求。
【参考文献】
rtsp协议篇5
关键词： Android； Web Service； 智能家居； 嵌入式网关； 视频监控
中图分类号：TP311 文献标志码：A 文章编号：1006-8228（2017）03-44-04
Abstract： For the smart home system controlled by PC has disadvantages in price， mobility and operation， a new design and implantation scheme of smart home system based Web Service is proposed. The embedded Web Service server and ONVIF video monitoring server are built by transplanting gSOAP， the client end is realized by using KSOAP2 development kit. Users can control and monitor the remote smart home devices via Android phone and tablet. The system has advantage of simple， low cost， portable and practical， and it is worth to be promoted.
Key words： Android； Web Service； smart home； embedded gateway； video monitor
0 引言
智能家居（smart home）系统通过将家居设备进行组网，将计算机技术和自动化技术进行整合，实现居家环境监测、视频监控、家电控制，以及危险预警系统等诸多服务，提高了人们的生活水平，现在正在慢慢走进人们的生活[1]。目前，大多数的智能家居系统采用PC机进行控制，这种控制系统造价高，不能移动，不方便操作。采用手机或者平板电脑远程连接家庭网络，可以方便快捷的实施监控[2-5]。但是，目前采用这种手机或平板控制的智能家居系统比较少，而且大部分的功能比较单一，界面设计简单，无法提供良好的用户体验。
本文提出了一种采用Web Service技术的智能家居系统实现方案。用户可以通过运行Android系统的智能手机或者平板，连接家庭网关，对家用电器进行远程控制，对居家环境进行远程视频监控。
1 系统硬件平台
智能家居网络总体框架如图1所示。家庭中各个网传感节点和Zigbee协调器组成星型通信网络。各个传感器节点和家居设备以Zigbee方式和协调器通信，协调器通过串口连接网关。本系统的网关采用基于ARM1176JZF-S内核，主频533MHz的高性能嵌入式芯片S3C6410。网关上组建嵌入式Web服务器和视频服务器，提供Web Service服务。运行在手机或平板上的智能家居控制系统客户端通过调用Web Service服务实现以下功能。
⑴ 通过获取温度传感器、湿度传感器、光照度传感器、红外传感器的数据，实现对居室环境数据进行持续的采集。
⑵ 对智能家电、智能窗帘和智能灯具等设备的控制。
⑶ 调用摄像机实现远程视频监控。
2 软件框架
2.1 程序架构
本系统采用目前流行的Web Service技术，实现安卓客户端和网关服务器之间的通信。Web Service是一种跨平台的分布式Web应用程序。Web Service服务由服务器提供，客户端可以在网络上的任何一个位置调用此服务。Web Service三个重要的组成部分是SOAP、WSDL（Web Services Description Language）和UDDI（Universal Description Discovery and Integration） [6]。SOAP是一个基于XML的轻量型分布式计算协议，定义了调用Web Service服务的标准方法；WSDL用于描述访问具体的接口的方式；UDDI用来管理、分发和查询Web Service。
软件框架如图2所示。客户端和服务器之间通过HTTP协议进行SOAP消息的传递。网关服务器运行Linux操作系统，提供基于SOCKET的HTTP协议通信协议。然后再移植开源Web Service工具gSOAP来提供Web Service服务所需要的XML解析器和SOAP处理器。
2.2 服掌鞫顺绦蛏杓
服务器端程序设计步骤：首先生成C/C++头文件；然后使用SOAP编译器编译后生成RPC服务框架和序列化的数据类型代码；最后将这些代码链接到服务应用程序中，就成为可供客户端调用的Web Service。gSOAP编译器同时会生成一个WSDL文档用于描述这些服务。
在本设计中，客户端的请求分为POST和GET两种方法。GET方法用来处理静态网页，进而为描述接口的WSDL文件提供支持。POST方法用来实现SOAP消息的传输，将接收到的HTTP数据包保存在内存缓冲区，然后再进行进一步的处理。网关服务器对SOAP消息的处理过程如图3所示。服务器在接受到客户端的HTTP请求以后，调用相关模块解析SOAP消息，然后根据解析结果提供相应的服务。最后将执行结果封装成SOAP响应信息返回给客户端。
2.3 视频服务器程序设计
采用建立在Web Service的SOAP通信框架基础之上的ONVIF通信标准，进行视频服务器设计。ONVIF通过定义网络视频设备之间信息交换的通用标准，以实现不同厂家的视频产品之间的互通性。ONVIF也是使用WSDL定义服务，使用XML语言描述数据，采用SOAP通信协议传输信息。ONVIF标准包括设备发现和设备管理两大功能模块，前者通过基于IP组播技术实现，后者通过传递SOAP消息进行通信。SOAP通信框架按照以下步骤生成[7]。
⑴ 登录ONVIF网下载WSDL文件，该文件描述了与媒体服务相关的Web服务消息格式、操作、数据类型、协议绑定和服务地址。
⑵ 从网上下载gSOAP 2.8.21工具，解压后得到的wsdl2h和soapcpp2文件。
⑶ 使用wsdl2h工具将WSDL文件转换成C/C++风格的头文件。
⑷ 使用soapcpp2工具将上一步产生的头文件生成服务器端提供SOAP服务的框架（Skeleton）代码。
3 安卓客户端程序设计
3.1 客户端与服务器之间的通信
在Android客户端平台上，调用服务器端的Web Service必须使用开发包KSOAP2，以实现SOAP协议的处理。KSOAP2是一个用于资源受限制的Java环境如Applets或J2ME应用程序的第三方类库。
安卓客户端通过调用服务器端的Web Service服务，通过对远程数据库的查询、控制和管理操作，从而实现对家居设备进行控制和监视。本设计采用的KSOAP2软件工具可以封装用户请求，以SOAP格式来调用Web Service，然后将返回的SOAP格式的数据信息解析为SOAP Objecet对象。KSOAP2调用Web Service步骤如下。
⑴ 下载Ksoap2-Android工具，并导入工程。
⑵ 指定Web Service的命名空间和调用Web Service方法的名称。
⑶ 借助Soap Object对象传递参数。
⑷ 生成调用Web Service方法的SOAP请求信息，并指定SOAP的版本。
⑸ 调用Web Service，根据返回的数据，解析出结果。
3.2 客户端设计
客户端连接服务器的第一步是登录，进行身份验证，其流程如图4所示。首先输入服务器的用户名和密码。如果服务器验证通过，就可以建立客户端与服务器之间的交互通道，在主界面中接收服务器响应数据帧，同时更新所有家居设备的状态信息。用户登录成功后，可以执行如下相应的动作。
⑴ 如果要控制设备或者查询设备状态信息，则通过Get方法发送控制帧或者查询帧。
⑵ 如果要执行视频监控则通过POST方法发送视频控制命令。
⑶ 如果用户需要更改密码，就要输入旧、新两种密码，如果密码匹配，则服务器返回响应码“201”，表示密码更改成功；否则可以向服务器发送控制或者查询请求，服务器收到后，先返回一个响应，然后执行相应的动作。
3.3 视频监控客户端设计
3.3.1 设备发现和管理
设备发现的主要目的就是获取ONVIF设备的服务功能和服务地址，为后面的视频数据接收和播放提供基础。ONVIF协议的设备发现模块可以让客户端发现服务器的RPC的入口，本设计采用WS-Discovery发现协议实现该功能。WS-Discovery [8]协议采用SOAP和UDP组播协议，客户端使用239.255.255.250：3702地址发送组播消息自动搜索ONVIF设备。服务器端的ONVIF设备收到组播消息后进行响应，客户端根据收到响应数据包来获取相应的设备信息，统计搜索到的设备个数。
3.3.2 流媒体数据接收及分片打包
网关服务器摄像头自带视频采集、视频压缩编码功能，输H.264格式编码的标准数据流。客户端通过RTSP会话接收服务器端的流媒体数据，一次完整的会话过程如下。
⑴ 连接服务器，同时发送一个RTSP DESCRIBE命令。服务器返回一个描述媒体类型、流数量等信息SDP。
⑵ 分析收到的SDP，为会话中的流发送一个SETUP命令建立RTSP。客户端通过此命令将自己的端口号告诉服务器。
⑶ 流媒体连接过程建立成功以后，客户端发送PLAY命令和TERADOWN来开始和结束视频的播放，还可以发送快进、快进和暂停命令。在播放过程中，服务器使用UDP发送流媒体RTP包给客户端。
本系统需要多个ONVIF IPC设备通信，为了提高数据传输速率和数据处理的效率，课题组采用Select网络模型完成标准的RTSP会话过程。
3.3.3 流媒体解码及显示
为了能显示视频，客户端需要首先移植FFMPGE。使用FFMPGE对接收到的RTSP流媒体文件进行解码，再将解码后的信息转换成为YUNV420P格式，然后再转换为RGB24格式。最后再转换成可在安卓设备上播放的ARGB_8888格式。转换完毕之后，就可以将每一帧显示在屏幕上。
4 结论
本文结合嵌入式系统和安卓平台优势， 采用目前流行的Web Service技术，设计和实现了智能家居系统的服务器端和安卓客户端程序。服务器端通过移植gSOAP和ONVIF协议来组建嵌入式Web服务器，提供Web Service服务。安卓客户端程序给予KSOAP2开发包进行设计，实现了服务器端的Web Service服务的调用。系统主要采用JAVA语言进行开发，具有结构简单，开发难度低的优点。系统操作简单、成本低、使用方便，可以实现家居设备的远程控制和居家环境的远程视频监视，给人们生活带来极大的便利，具有较高的使用价值和推广价值。
参考文献（References）：
[1] Lin H T. Implementing smart homes with open sourcesolutions[J]. International Journal of Smart Home，2013.7.
[2] 周恩，李文军，郑永军等.Android平台的智能家居控制系统设计[J].中国计量学院学报，2013.24（3）：261-265
[3] Z阳静，邹念育，雷冬鸣等.基于Android和WIFI通信的智能家居系统设计[J].大连工业大学学报，2016.1：67-71
[4] 黄成云，卢选民，李戈.基于Android的智能家居控制软件设计与实现[J].计算机与现代化，2014.11：102-105
[5] Kumar S. Ubiquitous Smart Home System Using AndroidApplication[J]. Computer Science，2014.6（1）.
[6] 龚瑞琴，毕利.基于Web Service的Android技术应用研究[J].电子技术应用，2014.40（1）：134-136
rtsp协议篇6
关键词 网络视频；视频点播；管理系统；流媒体技术
中图分类号 G2 文献标识码 A 文章编号 1674-6708（2016）161-0054-02
随着信息科技日新月异的发展，如今，电视台制作的各类节目，能够利用视音频压缩技术进行再加工处理，从而实现线上实时点播、传播等，相较于传统电视节目播出方式来说，这不仅扩大了电视节目的覆盖和辐射范围，也增强了电视台在新媒体纷起的市场上的竞争能力。对于电视台来说，IETF开发的预留协议（RSVP）和实时传输协议（PTP RTCP），以及LAN和Internet接入，为电视节目的实时点播与传播等，提供了良好的实现条件，而受众也能通过多媒体数据库管理系统，来更加便捷地检索和查询电视节目。
1 流媒体技术的相关概述
IETF在1996年将RTP公布为RFC正式文档，作为一种新型传输协议，它主要是为交互式话音、视频、仿真等实时数据制订而服务的，目的是为确保VoIP和视频等能够进行实时传输和点播。在节目传播时，一般都是基于UDP协议实现RTP运行。通常来说，RTP协议与下层传输层和网络层协议之间，不存在关联关系，能够与相匹配的下层网络或传输协议，实现协同工作。在此过程中，低层网络如果也具有相应的多播功能，RTP也能实现多目的数据传输。RTP协议主要由2部分构成：一是负责多媒体数据实时传送的RTP，其主要功能是进行数据传输；二是负责反馈控制、监测及传递相关信息的RTP，其主要功能是负责数据控制与反馈等。由于RTP协议通过控制包为应用程序动态提供网络信息资源，其自身并不提供资源预留，因此，再实际应用中，可以对RTP的数据收发进行合理的调整，从而实现网络资源利用最大化和服务质量最优化。
2 视频节目管理系统的特征
作为一种多媒体数据库管理系统，视频节目管理系统具有自己独特的特征，具体来说，有如下几点：一是可以实现多用户同时操作；二采用Windows标准界面和操作方法；三是平台开发以中文Microsoft FoxPro6.0及c++语言未基础。本系统通过文本、特征帧及片花来描述视频节目；同时，还可以进行片花播放和节目原版回放；系统可以对节目播放情况进行智能化动态分析，并以表格形式呈现出分析结果；用户可以通过访问网页，来检索和查询节目，并根据自己需求控制节目播放。
视频节目管理系统，具有七大主要功能模块，即文件、建档、检索、分析、设置、维护、退出等。文件功能模块：用户选择一个媒体文件，通过相应播放器就可以进行文件播放；建档功能模块：就是针对影片、音乐、广告等节目，分门别类地建立相应的档案，以供检索；检索功能模块：用户只要输入关键字，系统根据关键字，就可以检索相关的节目内容。此外，系统也能依据用户输入的节目编号来检索，或者根据节目类型进行检索；分析功能模块：格局节目库存和播放情况，分门别类地进行视频节目统计分析和节目播放情况统计分析等；设置功能模块：系统管理员可以对用户的相关信息进行管理，例如，增删信息或修改密码等。另外，也可以设置搜索路径，改变数据存储位置等；维护功能模块：主要是对系统进行维护和节目备份；退出功能模块：用户结束操作，退出系统。
3 视频节目管理系统和基于流的视频服务器
3.1 视频节目管理系统要求
为了对经过处理和压缩的视频节目进行有效管理，充分激发受众兴趣及与电视台的互动交流，系统利用现代通信技术进行高效、高质的节目管理。例如，综合管理已处理好的视频节目、节目搜索及节目编辑等，同时，还实现了系统与Internet的实时链接，开设收费电影网络频道等，从而为受众提供多元化服务。视频节目管理系统的具体要求如下：1）网络专线。作为电视台制编播网的一个子网，视频节目管理系统需要设置防火墙，以确保整个内网信息安全可靠；2）制作节目特征帧。提取每一个节目的特征帧，将该特征帧作为节目区分其它节目的显著特征；3）节目文本描述。根据节目的形式和类型，分别详细记录节目相关信息资料；4）节目分析。主要是对节目信息数据，进行动态管理分析，并以图表形式呈现分析结果，例如，节目收视率分析、节目播放类别分析等；5）回放。用户根据实际需求，回访所看过的节目内容；6）在线编辑。用户自行对所观看的节目内容进行播放、剪辑等；7）节目片花制作。用户根据实际需求，截取每个节目的10s～30s内容，作为片段，以达到宣传节目和吸引受众注意力的目的。
3.2 视频节目服务器存储设计
视频节目管理系统的数据，主要来自节目片花和特征帧，而用户对节目的访问，大多都是以只读形式，根据文字描述内容进行访问，因此，为了方便用户使用，一般都以分散存储的形式，分别采用相应的服务器进行存储。
1）视频节目服务器。该服务器存储的是已经进行数字化处理的视频节目，也可采用一般服务器进行代替；2）特征帧及片花服务器。特征帧和片花数据可以共用一个服务器。如果数据量相对较小，可以通过多个磁盘来拓展磁盘空间；如果数据量很大和用户访问量较大，也可以采取磁盘阵列和光盘阵列的方法，对相关的信息数据进行存储。只要存储体中储存有服务器的数据，用户就可以检索和查询节目内容；3）文件和WWW服务器。节目文本描述一般是存储在单个文件服务器中，出于经济性考量，也能够采用一般的文件服务器来储存这些信息。对于那些关于节目的文本描述，这些数据则通常是常驻硬盘，便于用户检索并提取节目片花或特征帧。所有的视频节目，都可以制作片花和特征帧，并制作成光盘进行长期保存或传播，而原版文件则会一直保留在系统中。
由于网上用户需求存在多元化，因此，网上视频服务系统 应具有点播和直播功能，以便更好地满足用户需求。现场直播能够将某一现场发生的新闻事件，实时传送到客户端，方便用户即时获取新闻信息。用户借助查询模块功能，就可以便捷地找到节目，进行点播或直播。对于系统来说，节目与RTSP之间是一对一的超级链接关系，用户通过系统链接发出RTSP请求，系统服务器就能响应并回送关于该节目的SDP描述。用户收到信息并进行确认，服务器便将RTP数据流发送给用户。在收到RTP包后，用户端会定期向服务器发送RTCP报文。服务器在回收报文参数后，对这些参数进行统计分析，目的是对流量进行科学、合理的控制，并发送相应的响应。当然，用户也能发送其他RTSP请求，实现节目的快进、后退、暂停、停止等功能，服务器对此都有相应的处理。
4 结论
随着数字信息科技的发展，以计算机技术、多媒体技术和通信技术为基础的交互式视频系统，日益受到人们青睐。通过该系统，受众能过根据自己的兴趣爱好，随时进行节目点播或直播。可以预见，基于流媒体的视频管理系统，将能为网络视频节目的发展，进一步拓展发展之路，为受众提供更优质、高效的视频节目服务。
参考文献
[1]李小锐.数字电视城域点播系统[D].成都：电子科技大学，2012.
[2]甘志洲.新型HFC网络小区电视节目管理系统的研究[D].重庆：重庆大学，2013.
rtsp协议篇7
【关键词】 远程教育;流媒体技术;卫星通信技术
【中图分类号】G252.24 【文献标识码】A 【文章编号】1001-4128（2010）10-0174-02
在我国，提高教育现代化、信息化水平，大力发展现代远程教育是《面向2l世纪教育振兴计划》的重要内容。利用互联网上的文本、语音、图像、视频等共享数据资源以及国家数字网进行远程教育，又是穷国办大教育的战略性措施。从中央到地方政府，都非常重视远程教育。根据我国基础教育的实际，教育部决定从2001年起用5到10年间在全国中小学普及信息技术教育，全面实施“校校通”工程，以信息化带动现代化，努力实现基础教育跨越式的发展。实施“校校通”工程，可以有多种方式，但对于经济欠发达地区和贫困山区建立远程教育基地，实现“校校通”工程和教育信息化，最好的办法是建立卫星地面接收站，运用数字卫星接收站设备接收及利用教育信息资源。这种投资少、见效快的办法，是一个非常适合我国发展远程教育的捷径。
随着Internet的发展，流媒体(Streaming Media)越来越普及，流媒体技术已逐渐成为互联网中视音频传输的核心技术，这一新技术的出现影响着人类的学习和生活，给远程教育带来了新的动力和生机。同时也对我们现有的基于Internet的网络教育提出了新的挑战。但现有的网络速度较慢，不能很好地支持流媒体的应用。而卫星通信网络能拥有很宽的带宽，故我们可以将两种技术有机的结合起来为我们的教育服务。流媒体―卫星相结合的远程网络教育突破了时间、空间的限制，实现随时随地授课；内容丰富涉及音视频、动画、图文、多媒体课件和名师上课的实际课堂实录等多种形式；较强的交互性和真实性大大促进了人类的有效学习。本文试图通过自己的实践，谈谈流媒体技术和卫星通信在远程教育中的应用以及之间的结合。
1 流媒体技术
1.1 流媒体的界定及其特征
流媒体是一种基于宽带技术的视频、音频实时传输技术，这个实时传输技术也被称作流式传输技术，简称流技术。在 Internet/Intranet中使用流式传输技术进行传输的媒体就称为流媒体，流媒体可以看作是流技术应用的具体体现。流技术在开始传输数据后首先在使用者端的电脑上创造一个数据缓冲区，在数据应用前预先下载一段数据作为缓冲，当网络实际连线速度小于应用所耗用数据的速度时，程序就会取用这一小段缓冲区内的数据，从而避免应用的中断。流技术根据实现原理不同，分为顺序流式传输和实时流式传输两种。流技术在流媒体上的具体应用是把连续的影像和声音信息经过压缩处理后放上网站服务器，流技术能够按照特定的顺序将文件发送出去，允许用户一边下载一边观看、收听，而不必等到压缩文件下载完后才观看。目前在流媒体上使用的流技术主要是实时流式传输技术。
1.2 常见流媒体格式和协议
①即时串流通讯协议（Real Time Streaming Protocol，RTSP）
Real Networks公司协助建立的一个用来传送串流媒体的开放网页标准。RealNetworks公司在Real System系统中率先实现了RTSP标准协议通信。RTSP协议通信是一种有状态的通信，在语法及操作上均与HTTP／1.1 很相似。目前，Real Server通过标准的实时传输协议RTP和Real数据传输协议RDT两种数据包格式将流媒体数据发送到RTSP客户端。
②实时媒体系列（Real Media：RealAudio、Real Video和Real Flash）
Real Networks公司的Real Media系列包括三类媒体格式，自1995年至今，Real Media已经成为业界公认最好的流媒体／接收解决方案。
③微软媒体服务协议（Microsoft Media Server Protocol，MMS）是Microsoft公司为自己旗下的Windows Media量身定做的流媒体服务协议，由于Microsoft公司的影响力，它的应用十分普遍。
④高级流媒体格式（Advanced Stream Format，ASF）
微软制订的一种数据格式，音频、视频、图像以及控制命令脚本等多媒体信息通过这种格式，以网络数据包的形式传输，实现流式多媒体内容。
除此以外， Quik Time Movie文件格式同样也属于流媒体格式，在相同速度下，它的质量应该是最好的。同时由于它完全兼容PC和苹果机，很多游戏的宣传录像都采用.mov 文件。同样的，Flash文件也是一种流媒体，它支持实时传送，网上风行的大量以.SWf为后缀的MTV文件都是它的杰作。
⑤资源预订协议(RSVP)
RSVP(Resource Reserve Protoco1)是一种支持多媒体通信的传输协议，它在无连接协议上提供端到端的实时传输服务，为特定的多媒体提供端到端的Qos协商和控制功能，以减少网络传输延迟。
2 同步卫星通信系统
2.1 同步卫星通信系统及其特点
卫星通信系统由卫星和地球站两部分组成。卫星在空中起中继站的作用，即把地球上行站发上来的电磁波放大后再返送回地球下行站。地球下行站则是卫星系统与地面公众网的接口，地面用户通过地球下行站出入卫星系统形成链路。由于静止卫星在赤道上空35786Km，它绕地球一周时间恰好与地球自转一周(23小时56分4秒)一致，从地面看上去如同静止不动一般。三颗相距120°的卫生就能覆盖整个赤道圆周。故卫星通信易于实现越洋和洲际通信。最适合卫星通信的频率是1～10GHz频段。为了满足越来越多的需求，已开始开发应用新的频段如12GHz，14GHz，20GHz及30GHz等频段。
卫星通信的主要特点如下：
2.1.1 优点：
①通信范围大，只要卫星发射的波束覆盖的范围均可进行通信，且通信费用于距离无关，这一点很适合我国的山区远程教育。
②不易受陆地灾害影响较大。
③建设速度快。
④易于实现广播和多址通信。
⑤可以自发自收进行监控。
⑥同一信通可用于不同方向和不同区域。
2.1.2 缺点：
①由于两地球站间电磁波传播距离有近72000Km，信号传输有较大延迟。
②10GHz以上频带受降雨雪的影响。
③天线易受太阳噪声的影响。
2.2 同步卫星通信系统设计方案的考虑
2.2.1 卫星通信系统选择的整体考虑
从国内外卫星通信系统在远程教育中的应用来看 ，卫星通信发展至今已有很多种类，但传统的卫星通信系统都是面向网络的，中间要通过地面的电信网络后再与用户相连，这样设计的流媒体远程教育系统依然不能避开地面网络的传输速度较低和传输费用高的颈瓶限制，故我们选用VSAT地球站，VSAT除了具有普通卫星通信网络的特点之外，它还有其自身的优越性：
①VSAT是面向用户的，它不通过地面网络，避开了地面网络的缺点。
②VSAT的天线采用的是小口径天线，安装非常方便，且价格低。
③VSAT的智能化（包括操作智能化、接口智能化、支持业务智能化、信道管理智能化等）功能强，便于一般的人们操作、使用。
从以上VSAT所具有的特点我们可以看出，采用VSAT方案非常适合于像我国这样经济相对落后且地貌广阔、人民分散居住的国家普及和发展远程教育。
2.2.2 卫星传输方案的考虑
①传输速率：目前，中央级的广播电视图象质量标准，在不降低质量的前提下，用MPEG-2压缩编码标准，速率应大于5Mbps。作为教学活动考虑，快速运动的图像并不多。为节省频带起见，图像和语音压缩编码后的速率控制在2Mbps左右，已能满足教学的要求。由于计算机网络技术的迅速发展，教师已开始舍弃传统的黑板，采用网络浏览器调用讲稿以及通过网络，直接调用多媒体课件，所以在已有的图像、语音通道外，附加了一个数据通道(2~19．2kbpB)用以传送教师的文稿等内容，但总的速率仍控制在2MbpB左右。
②传输波段：C波段由于传播条件好，器件实现难度较小，已被广泛使用。但现在频段已很拥挤，加之天线尺寸较大，也有不利的一面。近年来，Ku波段技术已趋成熟，且设备比较轻巧，天线尺寸小，便于构建系统，总体建设费用也不贵，考虑用Ku波段是可行的。Ku波段的最大缺点是雨衰严重，易造成系统接收不稳定。但采取适当措施，如上行功率控制等，可减少中断、质量严重下降等概率事件。
③卫星带宽：由于图像、语音及数据广播的总速率控制在2Mbps左右，租用2MHz多一点的卫星带宽(QPSK调制)即能满足。为了开通VSAT系统，另租用1MHz多带宽，满足数家校外站与主站之间的交互。这样，总的带宽为4MHz。
④管理系统：由于系统与现有的公共信息网有区别，是为了申请接受远程教育的人而提供其学习的教育系统，所以应附设了地址加密系统。同时要达到教育的目的，根据需要，有目的的播放。
3 基于同步卫星通信技术的流媒体远程系统设计
该系统由一个中心站和多个接收站组成，中心站将各种流媒体信息汇接处理成高速的数据码流，经调制、上变频放大后由大型天线向卫星发送。接收站利用小口径天线VSAT接收卫星转发的信号，解调取出授权的信息，提供给面向用户的各种应用。
4 基于同步卫星通信技术的流媒体远程教育特点
4.1 能提供高质量的视频效果。使用HTTP传输模式，当远端学生浏览一段视频录像时，由于网络带宽不稳定，视频在传输过程中的质量无法得到保证。但基于卫星通信网络的流媒体远程教育能很好的解决这个问题，使远端学生自始至终享受赏心悦目的教学图像。
4.2 下载时间短、与文件大小无关。视／音频流不需全部下载到客户端就可播放，延时时间很短，且与流媒体文件的大小无关，只与流媒体服务器、客户机和网络的性能有关。
4.3 客户端操作简单、交互性强。视／音频流既可用流媒体播放器播放，又能嵌入在Web的网页中播放，并提供回绕、快进或暂停等交互操作，直观方便。
4.4 传输费用低，覆盖面积广，不易受地区经济差异或网络运营商的影响，有利于我国远程教育的普及和发展，对于我国国民素质的提高和职业教育的发展有很大帮助。
5 结束语
基于同步卫星通信技术的流媒体远程系统的设计和实现给远程教育带来了强大的生机，它对于营造学校教学氛围、实现师生之间的良好交互起了革命性的作用。随着Internet基础环境的不断改善和卫星通信技术的不断提高，流媒体技术必将在各领域广泛发挥作用，给学习、生活、工作带来极大的便利，为我国的远程教育迎来一个崭新的春天。
参考文献
[1] Khan B H Web―based Instruction．New Jersey Educational Technolog3Publications，1 997
[2] Windows-Media-Overview．URL 省略/windows/windowsmedia/CN/technologies/services.asp
[3] Real system Producer Basic．URL：http：／／www．real networks com／ products／index html
[4] 李学明，李继，魏芳.远程教育系统及其实现[M].北京:人民邮电出版社,2000
[5] 陈功富,王永建.卫星数字通信网络技术[M].哈尔滨:哈尔滨工业大学出版社,2001
rtsp协议篇8
关键词：质量监测；手机视频；媒体传输质量指标；清晰度；平滑度
中图分类号：TN 919.81 文献标识码：A DoI: 10.3969/j.issn.1003-6970.2012.03.017
Research on Quality Monitoring Technology of Mobile Video
XU Li-zai
(Video Operations Center, China Mobile Group Shanghai Co.,Ltd., Shanghai 200135, China)
【Abstract】Compared with the existing internet data and voice business, mobile video poses higher command for wireless network. Because of the complexity of wireless network environment, it is difficult to maintain sufficiently stable network bandwidth for a long time, thus adversely affecting the real-time broadcasting quality of mobile video users. Therefore, real-time surveillance of video quality in every link plays a key role in early warning and consumer complaint processing. This article analyzes characteristics of mobile video streams, and proposes technologies and realization methods of mobile video quality surveillance. The video quality surveillance analysis system analyses real-time QoS index of mobile video, and is able to detect problems before user experience worsens and avoid possible bottleneck problems in the business platform. This technology guarantees the smooth development and popularization of mobile video business from the perspective of operation and network planning.
【Key words】quality monitoring; mobile video; Media Delivery Index; definition; smoothness
0 引 言
手机视频业务要求网络具有更大带宽、更强的实时性。过去IP网络在承载互联网数据业务时被认为可以容忍的一些缺陷, 辟如数据包传输中5ms的抖动或0.1%的丢失率， 在手机视频业务的承载传输中都是不容许的。这些缺陷可能引起在手机终端上出现视频图像的马赛克、黑屏等现象，降低用户的满意度[1]。3G网络相比2G网络具有更高带宽，更能满足人们对手机视频的需求，提高用户满意度。随着3G网络建设规模不断完善，手机视频业务在全球迅速发展，用户数量不断增加。由于手机视频的数据流量和在线用户的数量之间是非线性的增长关系，因此无法依据在线用户数的增长变化来预先判断或规划已建设好的业务平台是否能动态地满足用户对视频服务质量的要求。
随着用户对于手机视频业务质量要求的不断提高，用户关于视频播放质量的投诉也日益增多。由于手机视频播放业务使用过程是一个复杂的端到端过程，因此很难界定手机视频的质量问题是业务平台的原因还是IP承载网的原因。为了能够在线监测及评估视频业务平台提供的所有音视频数据包的服务质量，需要研究手机视频质量监测技术和实现方法，同时手机视频业务平台需要研究一套视频服务质量在线分析评估和实时告警的系统[2]。本文提到的视频质量监测分析系统可以实时分析手机视频业务的服务质量（QoS）指标，同时根据网络的性能来判断业务质量受影响的程度，做到在用户的业务体验变差前及时发现问题，解决问题（例如对视频业务平台及时提出需要进行扩容的需求依据），从而为用户提供高品质的手机视频业务；及时规避业务平台的可能出现瓶颈的问题，从运行维护和网络规划的角度确保手机视频业务的顺利发展和普及[3]。
1 技术指标及监测原理
视频质量监测针对每一路视频流数据包进行深层分析，实时计算出各种指标从多个层面反映视频流质量，其中最主要的指标为媒体传输质量指标（MDI：Media Delivery Index）、连续计数错误（Continuity Counter Error）、清晰度、平滑度[4-5]。
MDI为媒体流丢失率和延迟的组合评价指标，对视频流在网络传输质量进行评估的测量指标。MDI包括了两个参数延迟因素(DF: Delay Factor)和媒体丢包率(MLR: Media Loss Rate)。
DF参数表示视频流的延迟和抖动状况，即缓冲器需包含多少毫秒的数据才能消除抖动，可反映视频是否会出现图像失真，从而获得用户体验质量。另外DF参数还可确定每个网元在视频流传输路径中的影响，通过比较流入设备的DF参数与流出设备的DF参数，可确定该设备是否注入过多的抖动以至于影响视频传输。
清晰度指标能够真实反映块效应产生的感受偏离。
平滑度指标可以真实评价运动信息对视觉感知的偏差。
对于移动流媒体业务服务质量监测在RTSP层面的分析指标主要包括服务器RTSP请求响应时延分析、服务器媒体播放时延分析、QoE头字段分析和SDP分析[2]。
RTSP在体系结构上位于RTP，RTCP之上，它使用TCP或RTP完成数据传输。在使用RTSP时，客户机和视频服务器均可发出请求。通过视频服务器从收到RTSP请求到发出视频流的响应时延分析，可以反映出移动流媒体业务的业务请求的响应速度。
服务器视频播放时延用于描述当客户机与RTSP完成播放（PLAY）的命令交互，到发出第一个包含有效媒体信息数据包之间的时间间隔。
QoE头字段包括用于移动流媒体客户端和服务器协商移动流媒体客户端应发送哪些QoS Metrics，以什么样的频率发送等信息。
SDP分析包括的指标为：会话名、会话时间、会话使用带宽、用户信息、媒体类型（例如视频或音频）、传输协议、媒体格式、会话地址、媒体传输端口。
视频质量监测基本原理如下：数据采集点负责对视频流所
MLR参数即单位时间内丢失（或非正常）的媒体数据包的数量。MLR参数对异常数据包的检测非常重要，由于视频信息的数据包丢失将直接影响视频播放质量，理想的视频流传输要求MLR数值为零。实践中，由于具体的视频播放设备对丢包可以通过视频解码中进行补偿或者丢包重传，在实际应用中MLR的阈值可以相应调整。
连续计数错误通常是用来判断TS包连续计数字段是否连续。正常情况下计数连续，即CC_ERROR=0；若出现连续丢包，比如4号和5号包丢失，此时只有一处计数不连续，即CC_ ERROR=1；若出现间隔丢包，比如3号和6号包丢失，此时计数两处不连续，即CC_ERROR=2；若出现延迟，比如3号包延迟，此时计数三处不连续，CC_ERROR=3。因此包延迟对于连续计数错误的影响最大，间隔丢包次之，连续丢包影响最小。经过的网元进行数据采集，同时将采集的数据送到数据处理单元。数据处理单元根据原始采集数据计算出各种指标值，并将指标值送到分析评估中心。分析评估中心进行相关视频数据的全面分析，对视频质量的关键指标进行统计分析和存储，在出现指标值超出告警阈值时将告警信息发给报警处理单元。告警处理单元可以按照设定方式将信息发给监控人员。若视频质量问题是发生在监测分析点所覆盖的网络内，则可以重现发生问题时视频流质量情况；并且能实时监控分析点所覆盖的网络中几十万或上百万视频流的质量变化趋势情况，包括视频的各项指标和视频的回放。
2 系统架构及实现
视频质量监测分析系统分为数据采集层、数据管理层、分析应用评估层和用户接口层。系统软件结构示意图如下：数据采集层包括视频流采集、信令采集以及其他系统的基础数据采集；数据管理层包括视频流数据管理、告警数据管理、用户数据管理(手机号码)、指标数据管理以及其他数据管理；分析评估层包括视频指标分析、用户行为分析、异常分析、网络质量分析以及视频质量综合评估；用户接口层包括实时质量展示、告警提醒、用户情景再现(异常用户为主)以及其他自定义用户界面。
视频质量监测分析系统是一个分布式网络系统，总体上可以分为五部分硬件平台组成：前端数据采集点(网络线路数据分流器)，前端数据采集设备(带有1000 Mbps/10,000 Mbps的数据采集接口)，前端视频监测数据处理服务器，视频服务质量综合分析服务器及告警系统，监控终端等硬件平台。
视频质量监测分析系统在软件和硬件上都采用分布式架构。每个数据处理单元采用负荷均担的方式，使得资源得到合理分配和充分利用，整个系统始终处于稳定的最佳状态运行。后期随着用户数的增加，被监测分析的网络流量可能超出初期设计的系统容量极限，只要添加硬件处理单元即可，保证了系统升级的平滑过渡。
视频质量监测分析系统可向用户呈现所监测的所有视频流，以及相关的视频服务质量指标。具体功能包括：
视频流监控及同步播放功能，可实时追踪一个用户的视频流，和用户同步观看节目，检查与原始视频流效果是否一致。
故障视频流查询及回看功能，可查询选择故障视频进行回看、指标查询，回看的效果与故障发生时的效果能够达到完全一致。
直播业务质量分析，功能包括直播成功率和响应时延分析，直播失败原因分析，直播业务时长分析，直播业务访问排行统计。
点播业务质量分析，功能包括点播成功率和响应时延分析，点播失败原因分析，点播业务时长分析，点播业务访问排行统计。
用户投诉处理分析，提供用户业务记录和业务信令流程图，保存用户原始数据，精确分析每个用户的业务失败原因。
业务质量和失败原因分析，按照多种维度对全网的视频业务进行统计分析，实时监测业务平台的质量变化，具有实时预警告警功能。
3 结束语
技术分析以及演示环境模拟表明，本文提到的视频质量监测分析系统可以在高视频并发量的情况下做到实时分析手机视频业务包括媒体传输质量指标、连续计数错误、清晰度、平滑度等服务质量指标。同时可以根据网络的性能判断出业务质量受影响的程度，结合业务质量要求设置服务质量相关指标参数的报警阈值，能够做到在用户的业务体验变差前及时发现问题。视频质量监测分析系统可以为手机视频用户提供更好的视频服务质量，处理用户投诉等奠定技术基础，大大简化手机视频运营维护成本，提高运营维护效率。
参考文献
[1] 张弘. 数字图像处理与分析[M]. 北京: 机械工业出版社, 2007.
[2] 康晓东, 杨海英. 无线音视频处理、传输及其标准[M]. 北京:北京工业大学出版社, 2005.
[3] 刘峰. 视频图像编码技术及国际标准[M]. 北京: 北京邮电大学出版社, 2005.
rtsp协议篇9
【关键词】 SIP 融合通信客户端 软件体系架构
一、引言
目前，现代电力企业员工日常办公活动中，沟通交流越来越重要。而随着技术的发展，利用先进的技术打破当前通信手段（如电话、短信、电子邮件和多媒体会议等）中以设备和网络为中心的限制，实现只要通过最常使用的通信工具和应用，就可以便捷高效地与上级、同事、客户及合作伙伴保持联系，这是人们一直以来期望的目标，而移动性和统一通信的结合可以达成这个目标。本文将结合移动设备自有的特性，讨论统一通信移动终端的融合技术。
二、融合通信移动终端设计架构
2.1 融合通信移动终端概述
融合通信通常是指把计算机技术与传统通信技术融合一体的新通信模式，融合计算机网络与传统通信网络在一个网络平台上，实现电话、传真、数据传输、音视频会议、呼叫中心、即时通信等众多应用服务。随着移动互联的快速发展，特别是是近几年iPhone、Android等智能手机的快速普及，越来越多的移动设备开始进入企业IT环境当中。
2.2 融合通信移动终端面临的问题
融合通信移动终端设计的目标是要实现在任何地方、利用任何设备，与任何通信实体进行跨平台、跨地域、跨设备的透明通信，且能够保证网络安全通畅，这使得客户端设计面临以下的主要问题：（1）统一通信平台的多样化，如市场上拥有成熟统一通信产品的就有思科、华为、中兴、西门子、微软、IBM等等，如何保证客户端都能够和这些厂商产品兼容；（2）终端系统种类和运行环境多样化，如市面常见的就有iOS、Android和Windows Phone等；（3）移动网络多样性和复杂性，而企业出于安全性考虑，使得移动客户端接入需要考虑的问题变得复杂化；（4）业务功能的可靠性。如语音、视频等实时性业务对IP承载网的网络质量要求很高，而移动设备的网络一般都没有达到这么高的带宽，如何保证音频/视频业务质量。
2.3 融合通信移动终端总体架构
2.3.1 功能架构
结合融合通信的功能要求和所面临的问题，我们设计的功能框架图如图1所示：
移动终端：融合通信平台的用户侧最终呈现的应用。该客户端安装在企业工作人员或者顾客的手机上。
管道侧：用来为平台侧与终端侧传输数据。
服务端：平台侧依据SOA框架搭建，包括框架管理界面、逻辑处理层、接口层和数据层。平台侧为终端上的服务能力提供支持，其服务能力能够利用接口进行添加和扩展。
2.3.2 设计体系架构
为了解决移动终端开发所面临的问题，我们提出了基于中间件的开发模式，即把所有除实时音视频业务外的所有其他业务统一封装整合（如基于SOAP协议的Webservice），而对于实时性的音视频业务，采用通用的SIP协议和RTP/RTSP协议结合的方式处理。结构图如图 2所示：
实现原理：（1）所有非实时音视频业务全部通过中间件适配形成统一的WebService接口提供给客户端；这样可解决多种统一通信平台接入、多种业务系统接入的问题；所有协议使用Https协议进行传输，内容通过3DES加密和GZIP压缩，保证传输的安全性；（2）而所有实时音视频业务则通过SIP会话进行控制，具体协商通过SDP实现，所有业务添加对Qos质量控制支持，确保业务功能的可靠性；（3）实时音视频业务会话协商完成后，音视频数据流通过RTP/SRTP协议直接与统一通信对应的音视频服务器进行对接，确保通用性。
三、移动终端统一通信融合的关键技术
3.1 SIP协议
SIP由IETF RFC定义，用于多方多媒体通信。按照IETFRFC2543的定义，SIP是一个基于文本的应用层控制协议，独立于底层传输协议TCP/UDP/SCTP，用于建立、修改和终止IP网上的双方或多方多媒体会话。SIP协议借鉴了HTTP、SMTP等协议，支持、重定向及登记定位用户等功能，支持用户移动。通过与RTP/RTCP、SDP、RTSP等协议及DNS配合，SIP支持语音、视频、数据、E-mail、状态、IM、聊天、游戏等。SIP协议可在TCP或UDP之上传送，由于SIP本身具有握手机制，可首选UDP。
3.2 视频编解码
因为视频内容传输需要消耗大量的网络带宽资源，采用合适的视频编码技术也是系统的关键。根据已有的编码标准来看，能够适合码流在1M到2M，同时又能保证高清的图像质量，比较好的标准有MPEG-4、 H.264、VC-1和AVS几种。H.264属于下一代编码技术标准，是所有压缩技术里面压缩率最高的，在支持实时标清电视节目时只需要1.5Mbit/s带宽、点播电视只需要1.2Mbit/s带宽，其画质就可以达到DVD效果，这显然有利于未来通信与娱乐、有线与无线的业务开展。因此，从技术的演进来看， H.264视频编码标准被认为是下一阶段的必然选择。因此，本系统优先实现编码H.264。
3.3 业务质量控制
语音、视频等实时性业务对IP承载网的网络质量要求很高，为了保障语音、视频业务QoS质量，在局域网中将语音、视频业务与OA等信息数据业务采取不同的VLAN进行隔离，要求在交换机上作配置相应QoS策略，实现对语音、视频等实时业务媒体流优先转发。
四、结果展示
通过以上的技术研究，搭建起一台中间件服务器，作为与即时消息服务器、UC服务器和信息系统服务器进行数据传输的中间平台，使用这些服务器提供的开发开发接口开发所需要的功能。
同时，在苹果iOS系统上开发完成了“融合通信移动客户端”，主要功能包括以下功能：（1）移动应用门户：融合门户、OA等信息系统，形成统一的移动应用门户；（2）SSO单点登录：为所有移动化信息系统提供统一的认证功能；（3）通讯功能：个人通讯录、企业通讯录、群组、短信群发、智能搜索、快速定位、点击拨号、一号通、语音会议等业务功能；（4）即时消息：融合腾讯通即时消息功能，可与腾讯通PC版进行互通。
rtsp协议篇10
关键词 P2P；移动设备；无线网络
中图分类号TP39 文献标识码A 文章编号 1674-6708（2013）108-0198-02
0 引言
虚拟现实技术在这些年来发展迅速，已成为理论学者和商家争先竞逐的对象。具有浸没感、交互性和构想性的虚拟现实技术产生了极大的魅力，然而随着虚拟现实不断扩张的同时，一系列的问题也随之出现，首先是大规模虚拟场景下载的实时性与服务器端有限带宽的矛盾，如今各类虚拟场景的复杂度和规模迅速增加，但基于客户端/服务器的下载模式中，服务器能提供的下载带宽却极其有限。第二是服务器端的有限处理能力与多用户并发下载之间的矛盾，由于用户规模变得越来越大，在基于Client/Server的下载模式中，大规模用户对大规模场景数据的并发请求势必给服务器带来极高的负载，并可能带来服务器瘫痪。第三是大规模场景的海量数据和用户终端较小存储空间之间的矛盾，随着智能手机、平板电脑的大规模普及，虚拟环境的终端已渐渐从PC转移到PAD、手机等移动终端上，而与传统PC不同的是，PAD、手机的移动终端的存储空间非常有限，这样就成为虚拟现实技术在移动终端设备上普及的瓶颈。而本文主要关注的是第三个问题。
1 研究现状和发展动态
互联网发展至今日，在各个方面、各个方向都有很大的突破，在两个方向，一个是虚拟现实，一个是P2P，这两项技术这些年来取得了长足的进步，而将这两项技术结合起来的尝试也已出现。
众所周知，P2P技术最近在视音频流媒体上应用很多，诸如BT、PPSTREAM等视音频软件都是P2P技术的产物，于是我便想P2P技术应用在虚拟场景的传输上，然而，这两者又存在着显著的不同：1）视频、音频等媒体内容的传输往往只需考虑数据之间的时间相关性，用户对媒体内容的访问是线性的，而虚拟场景存储于三维空间中，传输虚拟场景传输更多考虑的是空间相关性和用户在虚拟空间中的非线模式[1]；2）虚拟场景具有同视频、音频等数据不同的数据属性，对造型复杂的几何数据其编码难度高于线性媒体内容；3. 就应用层传输协议而言，流媒体传输主要依赖实时流媒体传输协议（RTSP）[2-4]等协议，而虚拟场景的传输目前较多使用HTTP协议。[5]总结了渐进式传输过程中的数据通信模式。
2 链路捆绑及数据的可靠传输
个人多媒体网关（MPG）和多媒体用户终端（MUE），并配有传输3D互动媒体的相关协议。子系统将实现移动链路捆绑协议和丢包控制技术：移动多链路捆绑技术可缓解带宽分配冲突和提高带宽利用率，为3D互动媒体应用提供非中断的通信；丢包控制技术则可以提供一种低时延、高可靠的实时传输技术。
如图所示，假设个人多媒体网关MPG已经建立了稳定的互联网连接，且终端设备MUE也已经建立了与MPG的有效连接。在图示的场景中，MUE可以请求MPG为其建立多链路捆绑服务，也就是3G/4G链路（超级链路）以及WiFi链路（子链路）的捆绑。在捆绑完成的情况下，超级链路负责3D场景数据通信的信令，而子链路负责传送3D场景的基网格以及网格增量。因此一旦MUE移动超出MPG的WiFi覆盖范围造成子链路中断，基网格会通过超级链路传输，虽然通信质量会出现一定程度的下降，但超级链路不会受影响并将继续保持通信。MUE重新恢复WiFi连接后，通信负载又会动态地转移回此子链路。捆绑协议的设计实现如下所述：
1）MUE与MPG建立3G/4G网络连接，称之为超级链路；MUE请求将MPG作为与远程服务器进行信令交互；
2）MPG与远程服务器以TCP/IP协议进行通信，建立通信信道；再发送就绪信号ACK回MUE；
3）如果MUE可以与MPG建立一个WiFi连接，则：
（1）MUE向MPG发送一个链路捆绑请求；
（2）请求确认后，MUE将3D场景的请求信息通过超级链路发送给远程服务器；
（3）MPG将收到远程服务器传回的3D场景数据的基网格和网格增量数据通过WiFi链路传回MUE；
4）如果MUE与MPG只存在超级链路（3G/4G），则：
（1）MUE将3D场景的请求信息通过超级链路发送给远程服务器；
（2）MPG将服务器返回的3D场景数据（包括基网格和必要的网格增量）通过超级链路传回MUE；
5）MPG作为MUE的中继节点与远程服务器进行通信，传输3D场景的基网格和网格增量。
只要MPG保持稳定和可靠，链路捆绑协议对于远程服务器而言是完全透明的。尽管WiFi连接可能随时出现中断，只要保证MUE与MPG的超级链路能够有效地传输3D场景的基网格数据，此协议可以进一步延伸到提供高效的非中断服务。
3 结论
在阅读了大量相关文献之后，选择关键技术，进行可行性分析，设计程序模型的架构。然后进入编码工作，使用OPENGL ES等语言实现P2P场景传输技术并进行调试。在各种移动平台上进行测试，使结果趋向稳定。
参考文献
[1]Mayer-Patel K， Gotz D. Adaptive streaming for nonlinear media. IEEE Multimedia，2007，14（3）：68-83.
[2]Kuhn K. Using RTP and RTSP for real-time 3D interaction [thesis]. University of Maryland Baltimore County，2006.
[3]Brandt J， Wolf L， Kahmann V. Collaborative streaming in heterogeneous and dynamic scenarios. Communication of ACM，49（11）：58-63.