《毕业设计论文IPTV 机顶盒流媒体终端设计.doc》由会员分享，可在线阅读，更多相关《毕业设计论文IPTV 机顶盒流媒体终端设计.doc（45页珍藏版）》请在三一办公上搜索。
1、摘 要中国是举世闻名的美食大国，拥有五千年的饮食文化和巨大的餐饮市场，随着人民生活水平和生活方式的转变，餐饮业具有巨大的投资市场，被称为中国的黄金产业，但同样也应看到，餐饮业不仅面临着巨大的发展机遇，也面临着前所未有的挑战和考验。在如今的社会情况下，餐饮业只有具备完整的管理系统和先进的管理技术，才能将餐饮业发展的更好，一步一步的迈向全世界。而餐饮管理这个问题是需要很多方面的，包括优秀的人才，配套的设备等等，需要从事人员长期摸索，不断完善。关键词：餐饮管理 中国 人才 设备AbstractChina is a big country world-famous cuisine, with five
2、 years of food culture and great food and beverage market, as the peoples living standards and lifestyle changes, the restaurant industry has a huge investment market, known as Chinas gold industry, but also should be noted that not only the restaurant industry faces enormous development opportuniti
3、es, is also facing unprecedented challenges and tests. In todays social situation, only with a complete catering management system and advanced management technologies to the development of the restaurant industry better, step by step into the world. The problem is the need to manage this restaurant
4、 many aspects, including good people, matching the equipment and so on, need to engage in long-term exploration staff, and constantly improve.iKeywords: catering managemeng, China,talents,equipment 目 录摘 要IAbstractII目 录III第一章绪论11.1 餐饮业在中国的市场坏境11.2 论文的主要工作21.3 论文的内容及安排2第二章 流媒体技术基础42.1 流媒体简介42.1.1 Real
5、 Networks公司的RealSystem42.1.2 Microsoft公司的Windows Media52.1.3 Apple公司的QuickTime.62.2 流媒体系统中的关键技术62.3流媒体传输协议72.3.1 实时传输协议RTP与RTCP72.3.2 实时流传输协议 RTSP102.3.3 会话描述协议 SDP142.4 本章小结16第三章 IP机顶盒概述173.1 IP机顶盒的概念173.2 IP机顶盒的功能173.3 IP机顶盒的分类183.4 IP机顶盒的关键技术7183.4 本章小节19第四章 IPTV 机顶盒流媒体终端概要设计204.1 开发平台介绍204.1.1硬件
6、开发平台13204.1.2软件基础架构214.1.3开发连接方式234.2 通信协议设计234.2.1 通信协议栈结构234.2.2 LIVE555 Streaming Media 开源库16244.2.3 RTP负荷格式284.3流媒体播放的过程模型294.5 本章小结31第五章 IPTV 机顶盒流媒体终端实现325.1 流媒体播放器总体结构325.2 媒体数据接收模块325.3 TS流解复用模块375.4 解码播放模块395.5 总控模块405.6 本章小结40第六章 总结与展望41参考文献42致谢4342第一章 绪论1.1 餐饮业在中国的市场坏境 我国的餐饮业发展已有几千年的历史，但早期
7、并未大规模化，直到改革开放之后，餐饮业渐渐壮大，成为国家，机构和个人必不可少的一个行业。快餐是外国传进中国的一种餐饮类型，当它刚进入中国马上受到人们的热烈好评，比如麦当劳，必胜客等等。直到近些年，人们逐渐认识到快餐已经满足不鸟日常所需的营养，所以中餐渐渐的又崭露头角，成为中国主要的餐饮消费行业。当然，中国也效仿了西方的餐饮，1.2 论文的主要工作在IPTV业务的三种实现方式中，宽带+PC的方式最容易实现，但由于计算机操作复杂，需要一定的专业知识，这使得一大批毫无电脑常识却又有宽带娱乐需求的用户被挡在了门外；再有，利用PC显示器观看影视节目相对于电视机观看屏幕小并且舒适度差。而采用专用的IPTV
8、电视的方式一方面造价会很高，另一方面没有充分利用我国现有的普及率很高的普通电视，造成了资源的浪费。相比之下，IPTV机顶盒+普通电视的实现方式更适合在中国发展，用户只需要添加一个机顶盒就可用享受IPTV的服务。下文若未加声明，讨论的IPTV系统都是指的IPTV机顶盒普通电视的实现方式。在整个 IPTV 框架中最接近用户的用来接收和播放流媒体的终端，通常为 IP机顶盒，它是一个体积不大，可用在普通电视机播放从网络上实时传送的音视频流媒体的小盒子，IP 机顶盒必须支持要求的流媒体解码输出，IP 机顶盒作为 IPTV 的终端，是 IPTV 业务中与用户交互的主要部件，在整个IPTV中扮演重要的角色。
9、本论文的工作是通过研究流媒体传输控制协议，并分析STB810 IP开发平台的架构和软件开发方式，开发出具有视频点播功能的流媒体终端软件，实现网络流媒体的接收，实现音视频解码、播放和控制。1.3 论文的内容及安排 全文共分六章：第一章 绪论介绍课题背景，研究意义及论文主要工作和文章结构。第二章 流媒体技术基础介绍IPTV系统中的流媒体相关技术，并重点研究了流媒体传输与控制协议协议：RTP/RTCP，RTSP，SDP等，主要研究了RTP/RTCP的报文格式，及其在流媒体传输中的功能，RTSP的请求消息和应答消息的格式，RTSP的操作和方法。还要SDP协议在流媒体传输控制中的作用。第三章 IP 机顶
10、盒介绍IP 机顶盒的相关概念，功能，分类及其关键技术。第四章 流媒体终端的概要设计在前面章节研究的基础上，进行IP机顶盒流媒体终端的概要设计。首先研究了流媒体终端的硬件平台STB810的硬件组成及其功能与性能，然后研究其系统软件架构与API，在此基础上设计流媒体传输的协议栈结构，并分析了LIVE555 Streaming Media开源库的结构，给出了流媒体播放的过程模型。第五章 流媒体终端的实现介绍了流媒体终端各个模块的具体实现。首先给出了流媒体终端的总体模块结构，然后讲述了各个模块如流媒体接收模块，TS流解复用模块，音视频解码模块的具体实现。第六章 总结与展望对本文进行总结，论述了本文解决
11、的问题和以后的需要做的工作。第二章 流媒体技术基础2.1 流媒体简介流媒体是在网络中以流式传输的多媒体文件，主要是指视频/音频文件。流媒体的文件格式是采用支持流式传输及播放的媒体格式。流式传输方式是将动画、视频、音频等多媒体文件经过特殊的压缩方式分成一个个压缩包，由视频服务器向用户计算机连续、实时传送。在采用流式传输的系统中，用户不必像非流式播放那样等到整个文件全部下载到本地后才能看到其中的内容，而是只需经过几秒或几十秒的启动延迟后即可在用户的计算机上利用相应的播放器或其它的硬件、软件对压缩的动画、视频、音频等流式多媒体文件解压后进行播放和观看，多媒体文件的剩余部分将在后台继续从服务器下载。相
12、对于传统的网络媒体播放方式，流媒体技术有如下特点：1具有特殊的媒体文件格式。流媒体的内容是可以播放的压缩媒体码流，例如视频流、音频流等。但是流媒体文件定义了特殊的文件格式，以适应于流化和传输。和只能本地播放的媒体文件相比，即使相同的节目源，相同的编码方法，流媒体文件结构也大不相同。2使用实时传输协议。各种实时传输协议是流传输技术的具体实现，它规定或者建议了如何将媒体文件封装成数据包，如何传输，如何将数据包重组、播放。3使用缓冲区。客户端需要开辟大小合适的缓冲区，一方面保证了能快速启动播放，一方面能有效平滑网络传输的延迟和抖动。4具有强大的可控性。由于其独特的传输方式和文件格式，流媒体技术具有强
13、有力的可管理性和可伸缩能力，可以方便地控制流量、进行计费，可以有效地防止非法复制等。由于流媒体技术领域尚未建立权威性的工业标准，各家厂商纷纷推出以自己的标准和通讯协议所开发的系统。目前，国际上主流的流媒体技术平台主要有 Real Networks公司的RealSystem, Microsoft公司的Windows Media以及Apple公司的QuickTime.2.1.1 Real Networks公司的RealSystemReal公司的流式媒体解决方案长期在市场和应用中占有重要地位。RealSystem可分为以下几个部分： RealPlayer是Real公司开发的实时多媒体音视频播放工具，
14、通过这个软件，用户可以通过互联网接收新闻或广播，在线收听收看现场的音频视频直播，或者在自己的硬盘上欣赏下载下来的Real格式的音视频文件。 RealProducer可以将标准的音频或视频文件转换成流式媒体剪辑文件。用户可以很容易地创建流式媒体文件、转换音视频、直接从外部媒体设备录制，或者利用RealProducer Plus进行流式内容的实时广播。 RealSlideshow使用户可以将基本的图像文件转换成流式媒体展示文件，以便用于互联网。用户可以在RealSlideshow中以时间线的方式组织图像、添加背景音乐、将自己的声音加入、定制图像和流媒体展示文件的外观，以及将成果发送给朋友。Real
15、Presenter是一个能够将微软的PowerPoint幻灯片演示程序文件转换成用于Internet或Intranet中的流式媒体演示文件的程序。 RealServe是整个Real System中的核心，也是在流媒体领域里最有权威的服务器软件。它有如下显著特点：1.流式传输广告：2.访问控制：3.授权：4.防火墙；5.ISP Hosting， RealServer根据存在的用户帐户，使媒体文件可以被流式传输；6.Monitoring，监视器；7.RealProxy，用来存储流媒体文件的软件，一般被安装在局域网或ISP的代理主机上；8.RealSystem Administrator，基于Web
16、的控制台界面；9.多余源，可以使用多个源进行播放，如果一个源不可用，自动切换到下一个源；10.报告，可以创建包含历史数据和收集信息的报告文件；11.查看源代码，在RealServer中，用户可以看到SMIL文件的源代码。2.1.2 Microsoft公司的Windows MediaWindows Media技术将影音文件分为Windows Video和Windows Audio两种，分别对应WMV和WMA格式。Windows Media的编码方式向着高压缩比、低传输速率的方向优化，虽然其编码技术不公开，但这并不影响用户的使用。编码的压缩和解压缩过程都会通过相应的软件自动完成，微软公司提供的Wi
17、ndows Media Encode:软件就可以进行Windows Media格式的编码压缩，而Windows Media Player则是解压缩工具。做为一个专业的开发人员，也可以从Windows Media Format SDK中了解到更多有关编码的信息。对于制作完成了的视频、音频片断，用户自然希望将其发布到网络上。WindowsMedia Services系统能用于多种网络环境，工作方式分为单播和多播两种服务。可以承担视频点播、转播、实况直播等多种领域的应用。MMS协议就是“Microsoft windows Media Server”协议的缩写，用来访问并流式接收Windows Med
18、ia服务器中ASF文件的一种流式协议，它是微软公司提供的专门用于访问Windows Media发布点上的单播内容的协议。ASF是英文Advanced Streaming Format(高级流格式)的缩写，它是一个开放的标准，能以多种协议在多种网络环境下支持数据的传送。实际上ASF就是用于组织排列音频流、视频流、图像以及脚本命令等多媒体数据的一种数据格式，以数据包的形式通过网络传输。由于ASF格式是专门为在IP上传送有同步关系的多媒体数据而设计的，所以ASF格式的数据特别适合在IP网上传输。在这个基础之上，微软公司还为其加上了“同样适于在本地播放”的特性。2.1.3 Apple公司的QuickT
19、ime. QuickTime是一款在苹果机中非常流行的媒体播放器。许多Mac使用者都将Quicktime当作必备的多媒体播放程序。Quicktime是由实力强大的苹果公司推出的，苹果机上所有的音频/视频播放都是由它来完成的。Quicklime是最早的视频工业标准，在1999年发布的QuickTime4.0版本后开始支持真正的实时播放，其格式为MOV。视频压缩部分采用Sorenson Video技术，该技术支持VBR，它可以动态分配带宽，以尽可能小的文件获得最好的播放效果，并能使之在解压缩时获得平滑流畅的画面。Quicklime中自带了大量的视频和音频压缩程序，这些压缩程序各有其自身的特点：有的
20、压缩速度慢而解压缩速度快；有的压缩率极高；有些压缩方便使文件失真过多；又有此压缩方法适合压缩特定媒体类型的文件。用户可以根据应用的需求选择压缩方式。Quicklime Streaming是一种在网上向观众实时的传输多媒体的程序，它发源于现场直播的出现。它定义了三种传输方式，分别是：Unicast Streaming(单点流式传输)、Multicast Streams(多点流式传输)和Reflected Multicast Streams(反馈式多点流式传输)。要传输Quicklime流式影片就必须具备Quicktime Streaming Server流式服务器，它以RTP/RTSP作为传输协
21、议。Quicktime Streaming Server可以传输高质量的流媒体，并且可以为3000多的用户同时提供流式服务，它包含在苹果机操作系统的Mac OSX Server服务器中。2.2 流媒体系统中的关键技术 流媒体并不是单一的技术，它整合了多种网络以及音视频技术。与传统的媒体播放技术相比，流媒体技术的实现需要解决多项技术问题。 第一，多媒体文件需要经过编码压缩以适合传输。普通的多媒体文件尺寸很大，不适合使用现有的窄带网络传输。ITU-T与ISO/IEC是制定视频编码标准的两大组织:ITU-T制定的标准包括H.261. H.263. H.264；ISO/IEC制定的标准为MPEG系列。
22、常用的音频编码标准有MP3, WMA, AAC等。面向语音编码的标准有G.723.1，G.726，G729等。 第二，流式传输的实现需要合适的传输协议。由于Internet中的文件传输一般是建立在TCP协议基础之上的，但是TCP的特点决定了它并不适合于传输实时数据。故一般都采用建立在UDP协议之上的RTP来传输实时的影音数据。 UDP和TCP协议的主要区别是两者对实现数据的可靠传递特性不同。TCP协议中包含了专门的数据传递校验机制，当数据接收方收到数据后，会自动向发送方发出确认信息，发送方在接收到确认信息后才继续传送数据，否则将一直处于等待状态。与TCP协议不同，UDP协议并不提供数据传送的校
23、验机制。从发送方到接收方的数据传递过程，UDP协议本身并不能做任何的校验、可见在速度与质量的平衡中，TCP协议注重数据的传输可靠性，但带来很大的系统开销，而UDP协议更加注重数据的传递速度。 第三，流媒体传输的实现需要缓存。 Internet是以包传输为基础进行断续的异步传榆。因此多媒体数据在传输中要被分解成许多包，网络为各个包选择的路由不一定相同，而且UDP协议不提供数据到达的可靠性保证。故到达客户端的时间先后先会发生改变，甚至会产生丢包现象。为此，必须使用缓存技术来弥补数据的延迟，并重新对数据包进行排序，从而使影音数据能连续输出不会因网络的阻塞而使播放出现停顿。缓存的目的就是在某一段时间内
24、存储需要使用的数据，数据存储在缓存中的时间是暂时的，播放完的数据即刻被清除，新的数据将被存入到缓存中。因此，在播放流媒体文件时不需要太大的磁盘空间。以上所说的均为流媒体技术实现所必须具备的条件，其他的一些流媒体应用技术则是在这些技术的基础之上变化和发展而来的，最终的目的都是为了解决传输速度、压缩算法以及安全性等问题。2.3流媒体传输协议2.3.1 实时传输协议RTP与RTCPRTP是英文Real-time Transport Protocol的缩写，中文名称是实时传输协议，用于Internet上针对多媒体数据流的传输。它通常使用UDP协议来传送数据，起初是为“multicast”传输情况而设计
25、的，目的是提供时间信息和保证流同步，不过也可以用于一对一的传输情况。RTP协议主要完成对数据包进行编号、加盖时戳、丢包检查、安全与内容认证等工作。通过这些工作，上层应用程序可以利用RTP保证流数据的同步、并提供实时传输。RTP的标准号为RFC 18891，它有一个升级版RFC35503。两者的数据包结构完全相同，最大的不同就是RFC3550中改进了当RTP会话在短时间内涌进大量参与者的时候，发送RTCP数据包的时间间隔的算法，尽量节省了RTP会话所占用的带宽。发布RFC3550之后，RFC 1889并没有被注销。在当今的大多数应用中，RFC 1889仍然作为参照的标准。在网络结构层次中，RTP
26、基于TCP/IP协议栈，为上层的应用层程序提供接口。RTP是面向连接的，每个会话的参与者都维护着一份参与者名单，RTP中的控制部分RTCP监控会话的质量，向每个参与者反馈丢包情况，作为流量控制的参考信息。2.3.1.1 RTP报文RTP 的下层协议需要提供传输地址和端口以标识一个会话，下层协议通常是UDP。每种媒体使用一个 RTP 会话，使用自己的 RTCP 报文。RTP 报文由两部分组成：报头和有效载荷（Payload）。RTP 报头格式如图2.1所示。 图2.1 RTP报文头格式开始的 12 个八位组出现在每个 RTP 包中，CSRC 仅出现在混合器插入时，各部分的含义如下： V：vers
27、ion，RTP 协议的版本号，占 2 位，当前协议版本号为 2。 P：padding，填充标志，占 1 位，如果 P=1，则在该报文的尾部将填充一个或多个额外的八位组，它们不是有效载荷的一部分。之所以有填充位，是因为有些加密算法需要报文长度对齐。 X：extension，扩展标志，占 1 位，如果 X=1，则在 RTP 报头后跟有一个扩展报头。某些使用模式需对 RTP 协议进行扩展。 CC：CSRC 计数器，占 4 位，贡献源数量，指示 CSRC 标识符的个数。 M：标记字段，占 1 位。具体含义由应用定义，通常表明一系列数据包中某个包是边界，如视频帧中多个数据包的最后一个，或者音频从无声到有
28、声等。 PT：payload type,有效载荷类型，占 7 位。用于说明 RTP 报文中有效载荷的类型，决定了应用层对净荷的理解方式。在标准RFC3551中指定了音频和视频的缺省映射初集，其他载荷类型代码可进一步扩展，或通过非RTP途径动态定义。在任意给定时刻，RTP发送源发出的RTP数据包有单一的载荷类型，PT的值不是为复用相互独立的流媒体而设计的。 Sequence number：序列号，占 16 位。用于标识发送者所发送 RTP 报文的序列号，其初始值随机产生，每发送一个报文，序列号增 1。接收者通过序列号来检测报文的丢失情况，重新排序报文，恢复数据。 Timestamp：时间戳，占
29、32 位。时间戳反映了该 RTP 报文的第一个八位组的采样时刻，它与序列号一起为报文丢失检查、媒体时间同步等提供必要的参数。时间戳的值和数据流的类型有关，一个视频帧可能由几个数据包组成，这些包的时间戳是相同的。数据分组的时间戳应从采样时钟获得，而不是读取系统时间。 SSRC identifier：同步源标识符，占 32 位，用于标识同步信源。同步信源是指产生媒体流的信源，它通过 RTCP 报头中的一个 32 位数字 SSRC 标识符来标识，而不依赖于网络地址，接收者将根据 SSRC 标识符来区分不同的信源，进行 RTP 报文的分组。该标识符是随机选择的，一个应用不能有两个发送者具有相同的 SS
30、RC。 CSRC identifiers：贡献源（CSRC）标识符，每个 CSRC 标识符占 32 位，可以有 0-15 个。每个CSRC 标识了包含在该 RTP 报文有效载荷中的所有贡献源。贡献源是指当混合器接收到一个或多个同步源的 RTP 报文后，经过混合处理产生一个新的组合 RTP报文，并把混合器作为组合RTP报文的SSRC，而将原来所有的SSRC都作为CSRC传送给接收者，使接收者知道组成组合报文的各个 SSRC。2.3.1.2 RTCP报文RTCP 定义了五种不同的报文类型：发送者报告报文(SR)、接收者报告报文(RR)、信源描述报文(SDES)、结束报文(BYE)和特别应用功能分组
31、(APP)。它们携带不同的控制信息。其中 SR 和 RR 统称为接收报告。RTCP 报文由公共的报文头和结构化的内容组成。公共报文头占 4 个字节，包括版本号(V)、填充标志(P)、报文计数、报文类型(PT)、报文长度和 SSRC 字段。根据 PT 字段判别报文类型。 BYE 报文用于指示本机准备退出会议组，也可以不发送 BYE 报文指示离开，如果某个 RTP 成员经过一段时间不发送 RTCP 报文或某段时间没有收到某个成员的 RTP 报文时，就认为此 RTP 成员已经离开。APP 报文为应用程序自定义，同样名字的自定义报文可以有不同的子类型。详细报文格式见RFC18891和RFC35503。
32、2.3.1.3 控制功能RTP 的控制功能通过周期性发送 RTCP 报文实现。RTCP 的控制功能是每个RTP 系统必须实现的，并由内部功能模块定期自动执行。它主要提供一种基于接收者反馈的网络传输 QoS 监测机制，在 RTCP 的接收报告中包含了当前网络传输QoS 有关信息，如报文丢失率、报文丢失累计、接收到的最高序列号、平均延迟抖动以及用于计算发布接收报告往返所需时间的时间标签等。通过这些信息可以监测和评价网络传输 QoS 状况，并可采取适当的策略实施同步控制。SR 报告中包含有实际时间和相应的 RTP 时间戳，可用于不同媒体间的同步。RTCP 报文是可堆叠的，多个 RTCP 报文可以连接
33、起来而无需插入任何分隔符，从而形成一个复合 RTCP 报文，并作为下层协议的一个报文来发送。在复合RTCP 报文中，每个 RTCP 报文均被独立处理。由于 RR 报告在带宽允许的条件下要定期发送，因此每个复合的 RTCP 报文中至少包含一个 RR，并为第一个。为使新的接收者尽快收到信源标识符来标识同步信源，每个复合 RTCP 报文应包含信源标识符(CNAME)。RTCP 的接收报告不仅对发送者有用，而且对其他接收者和第三方监控都有用。发送者可以通过反馈改变发送的速度；接收者可以知道问题出现在本地、区域或者是全局；网络管理员或第三方可以仅接收独立的 RTCP 包来估计网络组播的性能。RTP 控制
34、的关键问题有两点，一是 RTCP 分组泛滥；二是规模较大时RTCP 报告的真实性问题。RTCP 的分组泛滥主要发生在大量成员同时加入到一个 RTP 会话时。RTP 协议中使用了时间重虑算法(Time Reconsideration Algorithm, TRA)来计算 RTCP 的发送间隔，根据是否随组规模扩大而立即调整 RTCP 发送间隔。TRA 分为有条件和无条件两种。无条件 TRA 只在每个间隔到达时计算下一次时间间隔，在等待间隔时间内，即使组内成员发生变化，已计算好的时间间隔也不发生变化。有条件TRA 根据组成员的变化随时调整时间间隔，一旦组成员数目发生变化，就重新计算新的间隔时间，以
35、前的时间间隔作废。有条件 TRA 是新版 RTP 协议解决瞬时多人同时加入 RTP 会话而导致 RTCP 占用带宽超出 5%而设计的。RTP 协议遇到的另一个问题是当群组规模变大，RTCP 报告的发送间隔也变大。这可能超过群组成员的有效期，从而导致某些成员的 QoS 报告不真实，甚至完全失去价值。RTP 协议本身不能解决这个问题，它依赖于更为健壮的网络组播传送协议的支持。2.3.2 实时流传输协议 RTSPRTSP( RFC2326)8全称为Real Time Streaming Protocol，实时流传输协议，是由RealNetworks和Netscape共同提出的，该协议定义了应用程序如
36、何有效地通过IP网络控制多媒体数据的传送。RTSP 在体系结构上位于 RTP 和 RTCP 之上，它使用 TCP或 RTP 完成数据传输。实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流相间是可能的，但它本身并不发送连续流。换句话说，RTSP对于多媒体服务器起到“网络远程控制”的作用。RTSP 连接没有绑定到传输层连接，如 TCP。在 RTSP 连接期间，RTSP 用户可打开或关闭多个对服务器的可靠传输连接以发出 RTSP 请求。此外，可使用无连接传输协议，如 UDP。RTSP 流控制的流可能用到 RTP，但 RTSP 操作并不依赖用于携带连续媒体的传输机
37、制。2.3.2.1 RTSP 消息RTSP 是基于文本的协议，采用 ISO 10646 字符集，使用 UTF-8 编码方案。行以 CRLF 中断，但接收者本身可将 CR 和 LF 解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。RTSP 消息类型包括：请求消息和响应消息。他们对于传输实体采用通用的格式。都包括一个开始行，零或多个头域，一个表示头域结束的空行，以及一个可选的消息体。 RTSP 的请求消息的格式如图2.2所示： 图2.2 RTSP请求消息请求行和标题行由 ASCII 字符组成。sp 表示空格符；cr 表示回车符；lf 域表示换行符。在请求行中包含这些信息：1统一资源
38、地址（URI）域是用户所要访问媒体数据的绝对路径，如：192.168.0.1：8554/usr/local/media/01.ts。2域是客户端使用的 RTSP 协议的版本号。现在使用的RTSP 协议为 1.0 版本。3 域描述了 RTSP 请求的方法；主要的 RTSP 方法有：DESCRIBE；OPTIONS；SETUP；PAUSE；PLAY；TEARDOWN。4标题行属于可选项。标题行由两部分组成：标题域名和相关值。5主体实体一般情况下很少使用，主要用于对标题行没有定义的标题进行扩展。 RTSP响应消息 与请求消息相对应的是 RTSP 的响应消息。服务器收到客户端RTSP 请求消息（TCP
39、/UDP）后对消息进行分析，并将分析和处理的结果使用 RTSP 响应消息返回给客户端。响应消息的格式如图2.3所示。 图2.3 RTSP响应消息除了用状态行取代了请求行之外，相应消息和请求消息的格式是相同的。实体主体包含请求消息所要获得额外信息。状态行所包含的信息包括版本号,状态码以及短语，他们组合起来表示客户请求所获得的结果。例如：如果媒体可以发送到客户端，则状态码应该包含“200”，短语包含“OK”；如果客户端没有被授权，则这两个域分别包含“401”和“Unauthorized”。一般情况下，状态码中的第一位表示客户请求结果的一般信息：“1”表示信息码；“2”表示客户请求成功；“3”表示用
40、户的请求被重定向（即URI 已经改变）；“4”表示客户请求有问题（如未授权或者请求不被支持等）；“5”表示目标服务器出错。2.3.2.2 RTSP操作与方法RTSP 在流媒体服务器和客户端之间建立和控制连续的音频/视频媒体流，当客户端向流媒体服务器请求连续的流媒体数据时，流媒体服务器负责提供播放和录制服务，RTSP 就像是服务器和客户端之间的“网络远程控制”，它提供如下操作： 从媒体服务器获取媒体：客户端可以请求一个节目的描述以及要求服务器建立会话来发送所请求的数据。 邀请媒体服务器参加会议：流媒体服务器可以被邀请加入一个会议来播放或者录制节目。 添加媒体到现存节目：服务器或者客户端可以互相通
41、报可用的新增加媒体。RTSP 的方法记号表示由请求 URI 确定在资源上所采用的方法，区分大小写，定义新方法不能以“$”开头，并且必须为一个记号。RTSP中很多方法与状态无关。RTSP中的主要方法如表2.1所示：表2.1 RTSP中的方法方法 方向对象要求作用DESCRIBEANNOUNCEGET_PARAMETERC-SC-SS-CC-SS-CP,SP,SP,S推荐可选可选从请求的URI中检索演示或媒体对象的描述信息，也允许使用客户可理解的可接收的头指明描述格式。从客户端发往服务器时，方法将请求URI的演示和描述发给服务器；从服务器发往客户端时，方法实时更新连接描述。方法用于获取演示或媒体描
42、述信息，也用于检测服务器和客户端的连接状况。OPTIONSC-SS-CP,S要求方法用于检测服务器实现了哪些功能，可在任何时刻发出，且不影响服务器状态。PAUSEC-SP,S推荐引起流发送的临时中断，如果请求的URI中仅包含一个流，则当前流的播放和记录被停止，当URI包含一个演示和几个流时，当前演示和流都被停止，重播时必须保证同步，PLAYC-SP,S要求方法告诉服务器以SETUP协商的方法发送数据，该方法必须在有SETUP方法发送成功的的前提下才能使用。RECORDREDIRECTC-SS-CP,SP,S可选可选方法根据媒体描述初始化数据记录范围，该方法所带的时间标志记录开始和结束的时间，如
43、果没有给出时间范围则使用演示描述的时间范围，如果演示已经开始则从现在开始记录。通知客户端连接到另一个服务器，它包含了强制头地址，指示客户发送URI请求。如果客户端要继续接收媒体，则需要对当前连接发送TEARDOWN，对新连接发送SETUP。SETUPC-SS要求方法决定客户端请求资源的传输机制，以可以对一个已经播放的流发送，要求服务器改变传送方法。SET_PARAMETERTERADOWNC-SS-CC-SP,SP可选要求用于设置请求中的演示或流的参数，该方法应包含单个参数。终止给定URI流的发送，释放相关资源。注：方向栏中C表示客户端，S表示服务器；对象栏中P表示演示，S表示流，所谓演示就是
44、指服务器提交给客户一个或多个流的的集合，并通过描述组成一个整体。 2.3.3 会话描述协议 SDP SDP（RFC2327）10的全称为Session Description Protocol，会话描述协议。SDP的目的是为了描述在会话公告、会话邀请和其它一些形式的多媒体会话应用的初始化时所需的信息。 SDP是一种纯粹的会话格式描述信息，它不是为一个特定的传输协议而规定的，它可以同会话通告协议(Session Announcement Protocol, SAP )、会话初始化协议SIP、实时流协议RTSP和超文本传输协议HTTP相结合。SDP的应用范围很广，不仅仅是用于多媒体会议路径的描述，
45、或协商多媒体会议内容或媒体编码，它更是为一般的目的而规定的。 在因特网组播骨干网(Mbone)中，SDP被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，包括支持的协议，需要的软件等。SDP连接好会话后，传送足够的信息给会话参与者。SDP可以利用SMTP,HTTP或会议通知协议(SAP)来传递会话信息。 SDP的目的是使人们可以通过它的描述参与到会话中来。在组播环境下，SDP有两个作用:它通告了一个会话的存在，同时提供了人们加入这个会话的方式。在单播环境下，SDP的作用只限于后者。所以，SDP对于会话的描述一般包含的信息有： 会话名称和意图； 会话持续时间； 构成会话
46、的媒体； 有关接收媒体的信息(地址等)； 因为任何会话资源都是有限的，参与是有限制的，所以SDP还会描述如下一些信息: 会议将要用到的带宽； 会议负责人的相关信息。 与RTSP协议类似，SDP信息也是文本信息，采用UTF-8编码中的ISO 10646字符集。一个SDP描述实例由许多行格式为=的字符组成。总是单个字符；由决定了其形式的结构字符串。”=”号的两边不允许出现空格。的每个域的值之间用空格格开。 一个会话描述由一个会话层(session-level)描述和若干个媒体层(media-level)描述所组成。会话层的描述适用于整个会话和所有属于这个会话的媒体;媒体层描述可以没有或有多个，对应于会话中的各个媒体。会话层描述由带有字符”v=”的行开始，一直到媒体层描述结束了；媒体层描述由带有字符”m=”的行开始，一直到下一个带有”m=”的行结束，并由此行开始对下一个媒体的描述，SDP描述文本的结
