rtsp协议范文第1篇

关键词：移动流媒体；实时流媒体协议；MINA；服务器

中图分类号：TP393文献标识码：A文章编号：1009-3044(2011)10-2380-02

Design and Implementation of RTSP Mobile Streaming Proxy Based on MINA Framework

HAN Dong-dong

(Southwest Jiaotong University Institution of Mobile Communication, Chengdu 610031, China)

Abstract: In this paper, a RTSP (Real Time Streaming Protocol) mobile streaming proxy server is designed and implemented based on Apache MINA (Multipurpose Infrastructure for Network Applications) framework. The proxy server may find applications in campus, hotel, and similar hot spots, to allow multimedia access with smart phones having WiFi functionality.

Key words: Mobile streaming; real-time streaming protocol; MINA; proxy server

伴随着国内第三代移动通信的建设热潮和移动互联网的普及，越来越多的人们开始在手机等移动便携终端上使用上网业务。网页浏览、邮件接收等单纯的文本数据服务已无法满足手机用户的需求。与此同时，手机用户对网络音视频需求正不断增加。目前国内一些主要的手机门户网站也提供视频服务，但是高昂的流量费用、有限的音视频资源、有限的手机处理能力以及现有“先下载再播放”的模式都阻碍了移动音视频服务的发展。相对于“先下载再播放”的模式，广泛应用于传统互联网的流媒体（Streaming Media）技术把连续的音频和视频数据流式的从服务器端发送到客户端，用户可以边下载边观看，而不必等待整个文件下载完毕。

鉴于上述情况，本文研究了RTSP实时流媒体协议，设计实现了一种基于Apache MINA的移动流媒体服务器，将流媒体技术应用于移动领域，并借助大部分手机都具有的WIFI模块向用户提供音视频服务，使手机用户接入互联网的音视频服务。该服务器将主要应用于公共热点等无线局域网环境。

1 移动流媒体协议RTSP

RTSP流媒体协议是目前业界最为流行和广为采用的移动实时流媒体协议。国内主流的在线视频网站优酷等均采用了这种协议。它实际上由一组在IETF中标准化的协议所组成，包括RTSP(实时流媒体会话协议)[1]，SDP(会话描述协议)[2]，RTP(实时传输协议)[3]，以及针对不同编解码标准的RTP负载格式等，共同协作来构成一个流媒体协议栈，如图1所示。基于该协议栈的扩展已被ISMA(互联网流媒体联盟)和3GPP(第三代合作伙伴计划)等组织采纳成为互联网和3G移动互联网的流媒体标准[4-5]。

RTSP协议是用来建立和控制一个或多个时间同步的连续音视频媒体流的会话协议。通过在客户机和服务器之间传递RTSP会话命令，可以完成诸如请求播放、开始、暂停、查找、快进和快退等VCR控制操作。SDP协议用来描述多媒体会话。SDP协议的主要作用在于公告一个多媒体会话中所有媒体流的相关描述信息，以使得接收者能够感知这些描述信息并根据这些描述参与到这个会话中来。SDP会话描述信息通常是通过RTSP命令交互来进行传递。RTP又称为实时传输协议，用于实际承载媒体数据并为具有实时特性的媒体数据交互提供端到端的传输服务，例如净载类型识别、序列号、时间戳和传输监控等[6]。

2 移动流媒体服务器

移动流媒体服务器一般位于两个不同的网络之间，起到网关的作用。服务器和移动终端之间为无线通信方式（WIFI或者3G），服务器到流媒体服务器之间一般为有线的、高速的互联网。

两种运行环境：1）无线局域网，在这种环境下，手机通过自身的WIFI通信模块连接到无线AP从而接入互联网，服务器可部署在AP和互联网之间；2）3G或者GPRS网络中，手机通过移动通信系统接入互联网，服务器可以部署在移动分组域的GGSN和互联网之间。

两种适用的方式：1）透明，该模式中用户不需要知道服务器的存在，不需设置，支持所有的手机客户端，但需要所在网络的支持，即所在网络的网关会识别移动流媒体的流量并将其转发到服务器处理；2）手动，该模式可以基于现有的用户所在网络，用户需要知道服务器的IP地址和端口，然后手动设置移动流媒体连接的。

考虑到实施的方便性，本项目的实验环境选为无线局域网，并使用手动的方式。如图2所示的实验环境。其中移动终端和服务器位于两个不同的网络中，移动终端不能直接访问服务器，但可以连接到服务器。

3 MINA框架

移动流媒体服务器基于MINA网络应用程序框架。MINA(Multipurpose Infrastructure for Network Applications)是用于开发高性能和高可用性的网络应用程序的基础框架。通过使用MINA框架可以省下处理底层I/O和线程并发等复杂工作，开发人员能够把更多的精力投入到业务设计和开发当中。MINA结构如图3所示[7]。

MINA的主要接口如下[7]：

1) IoService：这个接口在一个线程上负责套接字的建立，拥有自己的Selector，监听是否有连接被建立。

2) IoProcessor：这个接口在另一个线程上负责检查是否有数据在通道上读写，也就是说它也拥有自己的Selector，这是与我们使用JAVA NIO 编码时的一个不同之处，通常在JAVA NIO 编码中，我们都是使用一个Selector，也就是不区分IoService与IoProcessor 两个功能接口。另外，IoProcessor 负责调用注册在IoService 上的过滤器，并在过滤器链之后调用IoHandler。

3) IoFilter：这个接口定义一组拦截器，这些拦截器可以包括日志输出、黑名单过滤、数据的编码（write 方向）与解码（read 方向）等功能，其中数据的encode 与decode是最为重要的、也是你在使用Mina 时最主要关注的地方。

4) IoHandler：这个接口负责编写业务逻辑，也就是接收、发送数据的地方。

4 服务器系统结构

服务器需要连接客户端和服务器，因此结构上自然分为服务器端(Server Side)和客户端(Client Side)对称的两部分，如图4所示。

其中，Server Side用于与Streaming Media Server的交互，向服务器请求连接和数据。Client Side用于与Mobile Streaming Client的交互，负责响应客户端的请求。这两部分都是基于上述的MINA框架，MINA分别提供了IoAcceptor和IoConnector两个接口。其中Client Side需要实现IoAcceptor接口，Server Side需要实现IoConnector接口。图5为Client Side的接收手机连接请求的数据流。

5 系统功能

服务器系统的5个系统用例如图6所示。

本服务器实现的主要功能为实现RTSP协议信令，并根据需要修改部分参数，然后作为RTP和RTCP包的中继，进行数据转发，即上图中的RTSP协议流量。

视频转码作为一种可选的加强功能，系统调用第三方的插件如FFMPEG等对RTP数据包中的视频负载格式进行转化，如码率压缩等，将互联网上的视频转化为手机能够识别的通用的格式。

另外，本系统功能还包括用户接入认证，系统日志，系统配置等附加功能，可提高系统的安全性和健壮性。还可以考虑在视频播放前后或缓冲时插入广告视频等扩展功能。目前，可供配置的系统参数主要为Client Side和Server Side分别绑定的IP地址和端口，以及日志系统的相关配置参数。

在系统实验中，使用诺基亚Symbian S60手机模拟器（IP地址为192.168.11.3）播放流媒体服务器上的视频，该服务器为Darwin Streaming Server，IP地址为192.168.2.3。手机模拟器不能直接访问该服务器，只能连通服务器。

服务器具有两个以上的网卡，服务器的Client Side绑定IP为 192.168.11.4的网卡，Server Side绑定IP为 192.168.2.1的网卡，服务器在192.168.11.4地址上监听9554端口。

首先，打开诺基亚手机自带的RealPlayer,点击“选项”，然后选中“”进入设置，点击“使用”以激活服务，并将服务器IP和端口填入，到此手机配置完成。输入测试URL：rtsp://192.168.2.3:554/test.3gp点击播放。通过软件抓包分析和服务器系统日志，在服务器运行的情况下，可验证手机通过服务器顺利播放了在线视频。 而关闭服务器则无法连接。手机设置和播放截屏如图7所示。

6 结论

在研究RTSP移动流媒体协议的基础上，本文探讨了移动流媒体服务器相关实现技术。并基于MINA网络应用程序框架，设计并成功实现了一个适用于无线局域网的移动流媒体服务器。

本服务器可以部署在公共的热点，比如校园、酒店、飞机场、咖啡店等场所。移动终端可以在设置服务器后播放互联网上的视频，服务器会将处理后的视频数据传送的用户终端，并可以在在播放前后插入广告视频。

参考文献：

[1] Schulzrinne H,Rao A,Lanphier R.Real time streaming protocol(RTSP) [S],RFC 2326, 1998.

[2] Handley M ,Jacobson V.SDP:Session description protocol[S].RFC 2327,1998.

[3] Schulzrinne H, Casner S, Frederick R,etal.RTP:A transport protocol for real-time[S].

[4] ISMA 2.0:Internet Streaming Media Alliance Implementation Specification[S],2005.

[5] 3GPP TS 26.234 V6.1.0:Transparent end-to-end Packet-switched Streaming Service (PSS);Protocols and codes(Release 6)[S],Sep.2006.

rtsp协议范文第2篇

关键词:流媒体;编码方式;传输协议

目前在中国的宽带网络市场上，基于不同压缩编码方式的mpeg－1，mpeg－2，real，wmt，quicktime等各种流媒体技术的产品成了宽带网络的宠儿，日益受到人们的关注。

一、流媒体的概念与特点

流媒体是指运用可变带宽技术，在数据网络上按时间先后次序传输和播放的连续音/视频数据的一种格式。流媒体在播放前只将部分内容缓存，并不下载整个文件，在数据流传送的同时，用户可在计算机上利用相应的播放器或其它的硬件、软件对压缩的动画、视音频等流式多媒体文件解压后进行播放，这样就节省了下载等待时间和存储空间，使时延大大减少，而多媒体文件的剩余部分将在后台的服务器内继续下载。

流媒体数据流具有连续性、实时性、时序性三大特点，具有严格的前后时序关系。

二、流媒体系统

流媒体系统包括音/视频源的编码/解码、存储、流媒体服务器、媒体流传输网络、用户端播放器5个部分（如图1所示），原始音/视频流经过编码和压缩后，形成媒体文件存储，媒体服务器根据用户的请求把媒体文件传递到用户端的媒体播放器。

三、流媒体关键技术

流媒体系统中，影响流媒体播放质量的3个最关键的因素是：编码和压缩的性能与效率、媒体服务器的性能、媒体流传输的质量控制。

（一）编码/压缩

流媒体系统中的编码用于创建、捕捉和编辑多媒体数据，形成流媒体格式。

影响音/视频流的编码性能的因素很多：首先是编码效率，要求在保证一定音/视频质量的前提下，媒体流的码流速率尽量低，以达到压缩流媒体文件的目的。其次是编码的冗余性和可靠性，与普通多媒体文件压缩/编码不同的是，流媒体文件需要在网络上实时传输，因此必须考虑传输中数据丢失对解码质量的影响。在internet环境下，最典型的方法是多描述编码(mdc)。mdc把原始的视频序列压缩成多位流，每个流对应一种描述，都可以提供可接受的视觉质量，多个描述结合起来提供更好的质量。最后需要考虑速率调节的能力，一种方法是采用可扩展的层次编码，生成多个子位流（substream），其中一个位流是基本位流，它可以独立解码，输出粗糙质量的视频序列，其他的子位流则起质量增强的作用，所有的子位流一起还原出最好质量的视频序列。当网络速率变化时，可以通过调节流输出的层次来控制码流的速率，从而适应网络速率的变化。

（二）媒体服务器

流媒体系统中的媒体服务器用于存放和控制流媒体的数据。

随着流媒体规模的扩大，流媒体服务器的性能成为制约流媒体服务扩展能力的重要因素。流媒体服务器性能的关键指标是流输出能力和能同时支持的并发请求数量。影响流媒体服务器性能的因素很多，包括cpu能力、i/o总线、存储带宽等。通常单个流媒体服务器的并发数都在几百以内，因此为了具有更好的性能，目前的高性能流媒体服务器都采用大规模并行处理的结构，例如采用超立方体的结构将各个流媒体服务单元连接起来。还有一种方法是采用简单的pc集群的方式，这种方式下多个pc流媒体服务器用局域网连接，前端采用内容交换/负载均衡器将流媒体服务的请求分布到各个pc媒体服务单元。后一种方式的性能不如前一种方式，但是成本低，容易实现。

（三）流媒体传输网络

流媒体在因特网上的传输必然涉及到网络传输协议，这是制约流媒体性能的最重要的因素。为了保证对网络拥塞、时延和抖动极其敏感的流媒体业务在面向无连接的ip网络中的服务质量，必须采用合适的协议，其中包括internet本身的多媒体传输协议，以及一些实时流式传输协议等。

①internet本身的多媒体传输协议

rsvp(resource reserve protocol)协议预留一部分网络带宽，能在一定程度上为流媒体的传输提供qos。在某些试验性的系统如网络视频会议工具vic中就集成了rsvp。该协议的两个重要概念是流与预定。流是从发送者到一个或多个接收者的连接特征，通过ip包中"流标记"来认证。发送一个流之前，发送者传输一个路径信息到目的接收方，这个信息包括源ip地址、目的ip地址和一个流规格。这个流规格是由流的速率和延迟组成的。接收者实现预定后，基于接收者的模式能够实现一种分布式解决方案。

②实时流式传输协议

目前几种支持流媒体传输的协议主要有用于 internet上针对多媒体数据流的实时传输协议rtp（real-time transport protocol）、与rtp一起提供流量控制和拥塞控制服务的实时传输控制协议rtcp（real-time transport control protocol）、定义了一对多的应用程序如何有效地通过ip网络传送多媒体数据的实时流协议rtsp（real-time streaming protocol）。

rtp

rtp被定义在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。rtp通常使用udp来传送数据，也可在tcp或atm等其他协议上工作。rtp本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠rtcp提供这些服务。

rtcp

在rtp会话期间，各参与者周期性地传送rtcp包。rtcp包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型，以适应网络的带宽。通常采用两个方法来调节：一是窗口法，通过逐渐增大传送的码率，当发现网络上出现了包的碰撞，也就是检测到了丢包时，再减小发送的码率；二是基于速率的方法，先估计网络的带宽资源，再调整编码的目标速率来适应网络的状态。基于窗口的解决方案会引入类似tcp的重传，所以经常采用基于速率的解决方案。rtp和rtcp配合使用，能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

rtsp

rtsp在体系结构上位于rtp和rtcp之上，它使用tcp或rtp完成数据传输。http与rtsp相比，前者的请求由客户机发出，服务器作出响应；使用后者时，客户机和服务器都可以发出请求，即rtsp可以是双向的。rtsp是应用级协议，控制实时数据的发送，它提供了可扩展框架，使实时数据的受控、点播成为可能。该协议目的在于控制多个数据发送连接，为选择发送通道（如udp、组播udp与tcp）提供途径，并为选择基于rtp上发送机制提供方法。

四、结论

从技术的角度来说，对各种基于流媒体的应用影响最大的不是带宽，而是流媒体传输过程中的抖动和延时。网络的延迟和抖动影响数据包传输顺序的正确，使媒体数据不能连续输出，造成播放出现停顿。为了解决拥塞造成的抖动和延时问题，不但要求网络有足够的带宽,还要有较好的稳定性和可伸缩性。对等网络（peer to peer）以其各节点平权、资源共享的特点避免了传统的client/server模式中对server集中访问带来的网络拥塞，使网络有较好的稳定性。

rtsp协议范文第3篇

一、流媒体技术

简单地说，流媒体传输技术是由专门的流媒体服务器向用户连续、实时地发送声音、影像、动画等多媒体文件，这样用户可以不必等到整个文件全部下载完毕，而只需要经过几秒钟的启动延时就可以了。当这些多媒体数据在客户机上播放时，文件的剩余部分将继续从流媒体服务器下载。

流媒体实现的关键技术就是流式传输。流式传输定义很广泛，现在主要指通过网络传送媒体（如视频、音频）的技术的总称。其特定含义为通过Internet 将影视节目传送到PC机。流式传输的实现主要有两种方法，即实时流式传输（Realtime Streaming）和顺序流式传输（progressive Streaming）。一般说来，如视频为实时广播，使用流式传输媒体服务器，或应用如RTSP的实时协议，即为实时流式传输。如使用HTTP服务器，文件即通过顺序流式传输。当然，流式文件也支持在播放前完全下载到硬盘。流式传输的实现需要缓存，因为Internet以包传输为基础进行断续的异步传输，对一个实时A／V源或存储的A／V文件，在传输中它们要被分解为许多包，由于网络是动态变化的，各个包选择的路由可能不尽相同，故到达客户端的时间延迟也就不等，甚至先发的数据包还有可能后到。为此，使用缓存系统来弥补延迟和抖动的影响，并保证数据包的顺序正确，从而使媒体数据能连续输出而不会因为网络暂时拥塞使播放出现停顿。

流式传输的实现需要有合适的传输协议。TCP需要较多的开销，故不太适合传输实时数据。在流式传输的实现方案中，一般采用HTTP／TCP来传输控制信息，而用RTP／UDP来传输实时多媒体数据。

1．实时传输协议RTP与RTCP。RTP是用于Internet／Intranet针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多传输的情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议上工作。当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。RTCP和RTP一起提供流量控制和拥塞控制服务。RTP和RTCP配合使用，可以以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

2． 实时流协议RTSP。实时流协议RTSP是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。

3． 资源预订协议RSVP。由于音频和视频数据流比传统数据对网络的延时更敏感，要在网络中传输高质量的音频、视频信息，除带宽要求之外，还需其他更多的条件。RSVP是Internet上的资源预订协议，使用RSVP预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供QoS。

Internet／Intranet上使用较多的流媒体技术主要有Real System、Windows Media Technology和QuickTime，流媒体技术已广泛应用于远程教育、网络电台、视频点播、收费播放等，在企业一级的应用包括电子商务、远程培训、视频会议、客户支持等。

二、数字档案馆中流媒体传输流程

音频档案和视频档案再数字化工程中，得到相应的流媒体文件摘要。为了进行此类文件的网络播放，在江苏省电力公司数字档案系统中加入了流媒体解决方案。流媒体的具体传输流程如下：

1． Web浏览器与Web服务器之间使用HTTP／TCP交换控制信息，以便把需要传输的实时数据从原始信息中检索出来。

2． 用HTTP从Web服务器检索相关数据，A／V播放器进行初始化。

3．从Web服务器检索出来的相关服务器的地址定位A／V服务器。

4． A／V播放器与A／V服务器之间交换A／V传输所需要的实时控制协议。

5． 一旦A／V数据抵达客户端，播放器就可以播放了。

在采用流式传输方式的系统中，用户不必像采用下载方式那样等到整个文件全部下载完毕，而是只需经过几秒或几十秒的启动延时即可在用户的计算机上利用解压设备对压缩的A／V、3D等多媒体文件解压后进行播放和观看。此时多媒体文件的剩余部分将在后台的服务器内继续下载。这样，用户结合检索到的目录信息、文字说明、流格式声像档案片断即可清楚地知道录像带、录音带、光盘等介质的声像档案所囊括的内容。

三、数字档案馆中的流媒体系统

在江苏省电力公司的数字档案馆中，流媒体系统包括以下5个方面的内容：

1． 采编工作站。用于创建、捕捉和编辑多媒体数据，加工成流格式文件。

2． 视频服务平台。综合可扩展性、对各种多媒体格式的支持能力、压缩解压能力、连接数以及费用因素，数字档案馆系统中的视频服务平台采用的是微软的Windows Media 技术。

3． 声像档案数据库平台。

4． 网络平台。适合多媒体传输协议甚至是实时传输协议的网络客户端播放设备：供客户端浏览流媒体文件。

5．客户端计算机接收，解压缩，并播放内容。当传输实时内容时，视频和音频内容被编码并直接发送给服务器。然后服务器将内容发送给一个或多个客户端。

在数字档案馆系统中，媒体服务器采用Microsoft的Windows Media Server，音频档案和影像档案的再数字化处理成Mp3文件和ASf文件，以便流媒体服务器通过流媒体方式进行点播。数字化后的照片、音频和视频文件上传到媒体文件服务器上，然后进行数字化成果的数据登记和内容管理。工作原理如下图所示：

此外，江苏省电力公司制定了一系列关于声像档案的标准以实现规范化处理、管理、利用、保管声像档案。《江苏省电力公司声像档案数字化标准》确定了音频、视频档案转为数字化数据并加以存储的过程中的数据压缩方法、存储标准等。《江苏省电力公司声像档案数字化操作规程》从提取档案素材到采集参数的设定、采集前的准备工作、采集工作、采集后的工作都有详细的要求。

四、数字档案馆中流媒体系统的优点

1． 实现以纯软件的方式进行综合管理、制作、点播、提高系统整体的安全性和稳定性。

2． 先进的网络传送技术，充分利用网络带宽资源：100Mbps带宽下，单台服务器，500Kbps的MPEG4可达80－150并发流。

3． 点播视频内容响应速度极快。无需预读、不用等待，即点即播，快而准；任意拖动、绝无停顿，真正的流式解压技术。读取播放画面流畅、清晰。

4． 分布式体系、开放式传输协议。分布式体系设计、支持集群式接入，轻松实现大流量视频流并发。HTTP开放式传输协议，可轻松过网关或路由器，无需特殊设置，即可实现远程点播。

5． 开放的存储格式。不对存储介质作任何的特殊处理，采用标准的通用格式来完成视频源的存储。

6． B／S结构体系、Web界面管理。点播端、管理端均采用B／S（浏览器／服务器）结构，和Internet无缝结合，可方便远程管理。

7． 点播可控管理。可设定用户的访问权限，限制供点播的节目内容，可避免不适当的节目被不必要的使用者点播；具有用户分组及权限设置功能，管理员可以将用户分成不同的用户组，并可指定每组点播哪些类节目。

8． 负载均衡技术。采用媒体流负载平衡技术，能够最大限度地利用网络带宽。

9． 数据同步。稳定及时的数据更新，第一时间内的数据同步，确保客户端所见的永远为最新的数据。

rtsp协议范文第4篇

关键词：安卓；WiFidisplay；RTP实时传输

中图分类号：TP319 文献标识码：A 文章编号：16727800（2013）009010403

作者简介：陈子安（1987-），男，中国科学技术大学软件学院硕士研究生，研究方向为音视频编解码、嵌入式Android系统。

1WiFidisplay sink端基本架构

1.1WiFidisplay概述

WiFidisplay技术，是基于WiFi direct实现用户设备之间实时共享资源（图片、视频、音乐等）的技术。这种共享无需任何硬件连接（HDMI线），即可通过WiFi实时显示在电视、投影等大屏幕上。

从技术层面来看，WiFidisplay平台的应用主要是通过一个发送端（即Source，可以传送多媒体内容的WiFi终端，例如智能手机或平板电脑）和一个接收端（即Sink，可以接收并显示多媒体内容的WiFi设备，例如平板电视或投影机产品），建立一个点对点的连接，从而将手机拍摄的照片、影片或是网络上的高清视频内容完整地播放在拥有大屏幕的电视上；相反地，用户也可以通过手机或平板，直接观看电视或电脑屏幕上的内容[1] 。

由图1所示，android4.2在framework层通过wifip2p Manager提供了对wifidirect的支持。WFDSink是java层的实现，通过调用WifiP2pManager并在WifiP2pManager中加入detect 具有流媒体传输能力的source的功能，完成source端和sink端wifi连接的建立[2] 。WFDRTSPClient通过实现RTSP协议完成与source端的session建立。Session是一个基于RTP的会话，主要完成source端和sink端的能力交互，检测各自允许支持的最高音频传输格式和视频传输格式，并确认source端和sink端均支持HDCP协议（Highbandwidth Digitalcontent Copy Protection）。

source端通过建立的session将实时流媒体（或抓取的界面）以TS流的方式（transport stream）传送到sink端，sink端的WfdRealtime player 对传送的TS流先进行demux处理（为了提高传输过程的带宽利用率，音视频的传输都会在发送端先进行编码复用，因此接收端需要解复用），然后分别送到AV decoder里面进行解码，最后通过渲染并送入android的HWC Surface Flinger和Audio Flinger里呈现出来。

2WiFidisplay sink 端具体实现

Sink端系统主要分为WFDClient、Wifidirect_service、Wfdsession、WFDAVmanager、wfdrtspclient几个模块。

WFDClient 负责与Service端进行交互，查询WiFi display的状态，发送建立Session，连接Source的指令以及与用户的信息交互。

Wifidirect_service主要用于建立于Source端的wifi_direct连接，实现物理层的通信。Wfdsession将会在WiFidirect建立并完成Capatibility Negotiation之后建立流媒体传输的Session，建立Session的过程需要WFDrtspclient与Source端的rtsp通信。

WFDAVmanager与Android的Surfaceflinger和Audioflinger直接talk，实现WFD udp的数据接收，TS流解析，AV decoder以及AV renderer。

整个sink端的系统流程如图2所示。

2.1RTP/RTSP流传输协议实现

本文选用开源框架live555作为RTP/RTSP协议的实现框架。但由于live555不能观看实时采集的视频，不支持子目录的播放，因此在live555框架的基础上增加了live source、H264LiveStreamParser和H264VideoLiveMediaServerSubsession3个模块，如图3所示。

LiveSouree是实现doGetNextFrame接口的实时视频流的Source。由图3所示，LiveSouree继承了MediaSouree的功能，同时doGetNextFrame是MediaSource的纯虚函数，它允许其他的模块通过这个接口得到帧。

H264Videosink要求H264LivestreamParser通过MediaSource的接口每隔一段固定的时间段就传递数据给它。H264Livestreamparser是Livesouree的helper模块，它实现了doGetNextFrame，并且在doGetNextFrame的功能被其他模块调用时获得数据，比如RTPSink。H264 Livestream Parser为了达到与source行为一起工作的目的，还实现其他的细节处理功能。

H264VideoLiveMediaServerSubsession是一个用于管理Souree和Sink的类。

当一个用户连接到Media服务端时，H264 VideoLiveMediaServerSubsession对象被创建，直到连接断开才消失，当用户要从一个指定时间开始播放时，可以调用Seekstreamsource方法定位到指定的帧。H264 VideoLiveMediaServerSunsession创建的时候要创建LiveSource作为视频源。

2.2Demux （解复用）实现

Android并不支持对于MPEG TS流（MPEG定义的实时流传输标准）的复用和解复用功能[3] 。而根据MPEG TS的协议要求，TS流的Media Data传输都是以复用后的Packet形式存在。因此在实现Sink端的时候，必须对Source端传输过来的TS Packet进行Demux（解复用）。

解复用的实现方法是遵循MPEG TS协议的包格式进行字段解析。TS流信息都是二进制编码，可根据标准中定义的包格式中各标识符字段的含义提取节目表（PAT表、PMT表），从而解析出各节目对应的音视频流。

Demux实现的基本流程是：先接收一个负载为PAT（Program Association Table）的数据包，在整个数据包里找到一个PMT包的ID。然后再接收一个含有PMT的数据包，在这个数据包里找到有关填入数据类型的ID[4] 。之后就在接收到的TS包里找含有这个ID的负载内容，这个内容就是填入的信息。得到了PMT表的信息，就可以区分出TS Packet中的每一段数据分别属于哪一个节目的哪一路视频或者音频，这样就可以根据这些节目的信息分别将同属于一路节目的视频和音频送入对应的Decoder进行解码。

2.3AV decoder

AV decode 将实现对上述支持的音视频格式的解码。由于Android自带的Open Core不能支持上述的所有音视频格式的解码，需要自己编写Video Decoder和Audio Decoder。

Audio Decoder主要完成Audio的解码工作，包括与Audiotrack，Audioflinger的交互，Audio Decoder需要根据被解码的音频文件的格式、比特率，以及Audio Track的Buffer、Demux向Audio Decoder传送数据的速度等等一系列参数确定可用的最小Buffer Size。Audio Flinger向上对Audio Decoder提供调用接口，向下通过与Driver通信控制相应硬件，对于不同的格式，应该采取硬件解码还是软件解码，通过Audio Flinger获取硬件参数后如何确定解码算法，以及他们之间的Pipline交互，都是需要实现的部分。

Audio Decoder 首先获得编码的音频数据流，然后以帧为单位解码每一帧数据，这里需要根据对应音频的帧格式实现对应的变换算法，完成频谱包络解码，同时进行比特分配对尾数进行反量化处理，然后对频谱包络解码进行指数变换并和反量化后的信号合成滤波器组进行滤波，采样恢复，得到PCM数据[5] 。再将PCM数据划分声道，并做均衡、划分音量等级等等一系列处理，然后调用Player播放。在播放过程中要完成与Player的交互，包括每一路音频的速率控制、暂停、快进、快退、回放等操作Decoder的相应处理。

Video Decoder 跟Audio Decoder的流程大致类似，不同的是Video Deocder除了需要与Player交互实现Video的播放各种功能以外，还需要与Graphics交互实现画面的呈现，WiFidisplay需要播放实时流，它是一个界面的完整展现[6] 。Source端的界面抓取后传输过来，经过Video Decoder解码数据之后要送入图形图像处理模块进行显示，Video Decode需要根据图像输出的分辨率、刷新率等实时地调整送入Surface Flinger的数据速率，以及马赛克的处理、丢帧的处理等等。

3结语

WiFidisplay新一代的智能移动平台将彻底脱离“有线”传输高清数字信号的时代。本文基于ARM架构的嵌入式平台实现了WiFidisplay Sink端的功能，经过测试可与当前市面上主流的Source端配对良好并实时地传输Source发送的多媒体数据，具有良好的用户体验和可扩展性。

参考文献：

[1]宋碧莲，吴华平. 流媒体技术研究及其系统平台的设计与比较[J].计算机应用研究，2004，21（1）： 204207.

[2]ROB GORDON.Essential JNI：Java native interface，prentice hall PTR[J].12 million words，1998.

[3]ABHYUDAI SHANKER，SOMYA LAL.Android porting concepts[C]//2011 3rd.International Conference on Electronics Computer Technology，Kanyakumari.2011：916.

[4]陆其明. Directshow开发指南[M].北京：清华大学出版社，2010.

rtsp协议范文第5篇

关键词：3G技术；J2ME；手机视频监控

中图分类号：TP277

移动互联网飞速发展给人们带来了多样化的网络智能终端与互联网功能，人们只需将所需的应用程序安装在手机上即可享受此程序所带来的服务，人们完全能够实现在办公和生活。并且随着3G时代的来临，手机视频监控系统将会逐渐成为3G视频应用中的重点，在通过手机视频监控系统进行道路管理、公安执法、街道巡查以及事故应急指挥等操作已经基本实现，而在手机视频监控系统中所采用的J2ME技术更是为手机客户端进行远程视频接收与查看提供了更为便捷的方式，J2ME技术通过服务端口进行摄像和数据采集，并将数据传送至中心服务器进行视频图像压缩，为用户提供高清流畅的视频资源，用户只需通过手机即可对所需视频进行浏览。

1 关键技术

1.1 H.264技术

H.264是由ITU（国际电信联盟）和ISO（国际标准化组织）联合组建的数字视频压缩格式，在ITU-T中其是以H.26x系列为名称命名，在ISO/IEC中，它又被称为MPEG-4高级视频编码。H.264技术的提出主要为了在现有的视频编码标准器的基础上进行带宽优化，为相同带宽下的使用者提供更为优质的视频图像。H.264不仅能够为用户提供连续性的流畅高质量视频图像，还具有极强的容错能力，让使用者在网络环境不稳定的情况下避免出现数据丢失的情况。采用先进整数变换、帧间预测与帧内预测技术的H.264系统技术具有超高的数据压缩比率，能够使高清流畅的视频图像顺利传送至用户接收端口，在传输过程中实现带宽减少，节约数据资源。

1.2 J2ME技术

J2ME又称Java ME，其包括JVM规范与API规范技术，是通过JCP制定、与Java SE、Java EE并称Java技术的三大版本。J2ME的虚拟机技术可以为用户提供无线和有线连接，使用户能够随需进行应用程序的使用。J2ME采用了JAVA虚拟机技术为各类的嵌入式消费电子设备提供JAVA语言平台，是一种高度优化下的JAVA运行环境，其运行目标多样化，能够满足各方面的用户需求。

1.3 RTSP协议

RTSP不仅是一种实时流传输协议，同时也是TCP/IP系统中的一项应用层协议，其可以有效控制流媒体数据进行有线或无线网络数据的传送，还能够为用户提供视频模式的远程控制功能，包括对视频图像进行快进、后退、停止和定位等基本操作，RTSP还允许用户进行同时多个串流需求控制，在服务器端口可根据需求选择是否使用TCP或UDP来进行数据内容的串流传送。除此之外，RTSP还可根据实际负载情况进行服务器转换和重新导向加载功能，避免数据负载造成服务器延迟，并通过与低层协议结合为基于网络环境下的数据传输提供流化服务。

2 基于J2ME的手机实时监控系统的设计

2.1 系统设计

手机视频监控系统体系结构如图1所示，手机视频监控系统主要由前端采集、中心服务器和客户终端构成，通过前端采集视频图像，并在监控中间的服务器中进行数据分析、整理并压缩，最后通过有线和无线网络环境传输至客户终端进行视频图像的释放。

2.2 客户端

监控系统客户端口通过了J2ME平台进行设计，主要用于满足用户登录需求与信息的收发，客户端读取服务器响应信息后自动选择视频数据源来接收图像并实现实时播放，同时可以根据用户需求进行视频切换、屏幕图案捕捉、保存视频信息等处理，用户只需通过服务器登陆并进行验证，在通过验证后从服务器发送的视频设备列表中提取需要的视频源，选择接收视频图像即可，在视频播放期间还可进行各种基本的简易操作。

2.3 视频服务器

该系统既要向终端提供和传输图像，还要给客户提供可在web端口进行浏览的视频数据，这就要求J2ME系统必须满足不同客户端口的数据传输要求，设置不同规格的视频压缩模式。可采用低码流、高质量图像的H.264来进行视频压缩。H.264的转码模块主要由核心转码器、接收和发送模块构成，接收模块与网络监控相连，为用户提供调用指令，同时接收和提取来自监控端口的格式编码、帧率、分辨率和码率等视频流，核心转码器将视频流信息转换成H.264视频格式，并同步用户选择来修改视频分辨率，转码后进行TS/ES流分装，最后通过网络为用户提供视频数据。

3 基于J2ME的手机实时监控系统的实现

3.1 服务器端

服务器开发工具为VC6.0，采用了Windows 2003 sever操作系统，是一款微软制作的C++编译器。在操作过程中，先采用InitStreamClientLib函数对系统进行初始化，同时利用StartServer函数初始化服务器，接着启动流媒体服务器，设置本地文件路径，再启用Run Server函数启动服务器端口，如果需要结束服务端软件，调用停止服务系统，再关闭系统服务即可。当服务端口接收到用户需求信息时会自动开启独立数据传输与客户端进行数据连接，然后利用图像捕捉系统进行图像捕捉并压缩，最后将经过处理的图像以JPEG的格式发送至用户的手机接收端口。

3.2 手机客户端

手机系统客户端是一种方式移动信息设备程序，支持用户在MIDP设备上运行MIDP应用并利用仅利用MIDP规范各种API的运行。其中WTK（Sun J2ME Wireless Toolkit）是Sun开发者研制的一款无线开发工具包，目的在于帮助开放人员更为便捷的进行J2ME的开发。而Eclipse（集成开发环境）则为无线开发者提供了一个全新的框架服务，并通过插件组件为使用者构建一个统一的开发环境。手机系统客户端利用多样化线程为用户进行不同数据的传输与存储，同时调用socket来与服务器端口进行通讯，为了给使用者一个更好的用户体现，手机系统客户端界面选用了MIDP（移动信息设备配置文件）来显示用户图形界面，其主要运用程序包括Choice Group、Alert、Item、Form、Text Field、List等。在系统线程中主要使用的网络连接主要通过Java.lang.Thread来进行数据传输，并未用户提供Socket UDPDatagram Connection、Connection、ServerSocketConnection数据源接口，使MIDlet在TCP/IP层能够通过socket作为BSD UNIX的进程通信机制来描述端口和IP地址。

4 结语

综上所述，基于J2ME的手机实时监控系统的设计在近些年来已经逐渐成为3G时代下视频应用的重要组成部分，使用者通过手机客户端对服务器端所传输的数据来对视频进行浏览和查看，为网络数据的传播提供了多元化的方式。且随着J2ME系统中关键技术的进步和发展，J2ME手机实时监控系统将会为人们的生活提供更多的便捷服务，其在未来必然会拥有广阔的发展空间。

参考文献：

[1]夏帮贵.J2ME的手机视频点播系统设计[J].电脑编程技巧与维护，2009（12）.

[2]刘桂英，周琴.基于J2ME平台的手机实时监控的实现方法[J].工矿自动化，2008（1）：67-69.