（计算机系统结构专业论文）嵌入式媒体实时点播系统的设计与rtsp的实现.pdf

i 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 摘摘 要要 家庭媒体服务器快速发展成为家庭娱乐的主要来源设备，提供给家庭一个媒体 文件存储、管理、刻录、存档的中心位置。在家庭媒体网络中，服务器端使用高性 能的个人计算机，而客户端由多种嵌入式系统构成，代表性的设备有嵌入式数字电 视机顶盒。对于客户端来说，其嵌入式系统的处理器主频较低，解码器为一到两个 硬件处理单元，负责解码特定格式的媒体文件，功能较为专一。 鉴于这种服务器客户端架构，比较合理的vod点播方式是服务器端以客户端 上能解码的多媒体文件作为统一的格式进行发送，客户端只需接收单一的媒体压缩 格式进行解码。同时鉴于网络上视频格式的多样性，需要在服务器上实现多种格式 的媒体格式实时转换，然后传送给客户端，在媒体格式转换中用相关的协议对转换 流程进行控制，从而实现多种格式的实时vod点播。 研究了服务器客户端的架构，详述了服务器端多媒体文件压缩格式的转换，以 avi文件为例，设计了avi文件的读取，音视频分流，数据流解码，编码为统一音视 频格式的流程，以及rtsp服务器端的实现与缓冲区设计。嵌入式媒体点播系统数字 电视客户端的软件层次结构与开发环境分析，与rtsp客户端的实现。 研究的嵌入式客户端基于 st7100 芯片的开发平台， 开发平台提供了基本的网络 接入条件。 操作系统是支持 sh-4 的嵌入式 linux。 在 linux 操作系统和 st 中间件的 基础之上实现了应用软件。 测试结果表明系统实现的功能达到了预期流畅播放的效果，avi文件中包含 mpeg-2的标清视频流，与包含mpeg-4的标清视频流同样可以流畅播放。 关键词：关键词：嵌入式系统，视频点播，实时流协议 ii 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 abstract family media server becomes the center of the family entertainment. it provides the services of storage, management, burner and archived. family media center is formed by the high performance of personal-computer as the server and multi-embedded systems as clients, such as the set-top-box. most of the embedded systems have a low frequency mcu, and one or two video encoders. so it suits to handle singular encoded media streams. as the server-client structure, it is suitable for the server to send the stream data as the compression which can be decoded by the hardware on the client. as there are kinds of media formats on the internet, it is suitable for the server to deal with the multi-formats media to a singular one for the embedded client. realize real-time multi-formats vod system. finish the research on server-client framework. realize the transform of the format of multi-media files. take the avi files as the example, realize the extract of stream data from avi file, the separate of audio and video streams, the decompress of data streams, the compress of data streams, the design of rtsp server, and the buffers. analyze the software structure and the development environment, realize the rtsp client. the research was based on st7100 platform which provides basic network access ability. operation system was embedded linux supporting sh-4 cpu core. the application was based on the linux and middleware of st. test results show that the function is expected to achieve the smoothly broadcasting of media files on family media server. the avi files which contain mpeg-2 video and mpeg-4 video can be broadcasted smoothly. key words: embedded system, video on demand, real time streaming protocol 独创性声明独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得 的研究成果。尽我所知，除文中已经标明引用的内容外，本论文不包含任何其他 个人或集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和集 体， 均已在文中以明确方式标明。 本人完全意识到本声明的法律结果由本人承担。 学位论文作者签名： 日期： 年 月 日 学位论文版权使用授权书学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，即：学校有 权保留并向国家有关部门或机构送交论文的复印件和电子版， 允许论文被查阅和 借阅。 本人授权华中科技大学可以将本学位论文的全部或部分内容编入有关数据 库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。 保密， 在 年解密后适用本授权书。 不保密。 （请在以上方框内打“” ） 学位论文作者签名： 指导教师签名： 日期： 年 月 日 日期： 年 月 日 本论文属于 1 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 1 绪绪 论论 1.1 vod 的基本概念的基本概念 vod（video-on-demand）1-3，也称交互式电视点播系统。传统的电视系统信 息单向传送，用户只能被动接收。而vod是以“用户自主”的崭新概念为基础的双 向语音视频信息系统，实现了按用户需要播放语音视频节目的理想。vod是未来信 息高速公路构架的重要组成部分，是信息服务中宽带业务的灵魂。该技术是计算机 技术、网络通信技术、多媒体技术、电视技术和视频压缩与传输技术等多学科、多 领域融合交叉结合的产物。 1.2 vod 的发展和预期的发展和预期 国内vod视频点播技术最早出现在酒店宾馆等娱乐场所， 随着卡拉ok的兴起而 出现。最初应用于卡拉ok的vod系统是“半自动”的，每个点播房间对应一台位于控 制中心的影碟机，控制中心有操作员根据用户点播请求向影碟机中放置相应碟片， 一个熟练的操作员同时管理八台左右的影碟机， 这种vod系统由于要借助手工操作， 稳定性差，并且当多个用户点播同一个节目时，排队等待时间较长4。 第二代的vod系统是将所有节目放在服务器硬盘中，点播终端通过局域网或有 线电视同轴电缆（hfc）将点播请求上传至服务器，服务器进行相应播放。第二代 vod系统未对视频文件进行充分优化，客户端需要专用的视频压缩卡及专用程序， 难以支持大规模的并发点播，维护量大，不适于在小区或城域网环境中应用。 第三代的vod系统是目前最先进的，基于web平台进行设计，可与internet接入 并平滑地结合在一起：客户端采用浏览器方式进行点播，基本无需维护；由于采用 了先进的集群技术，可对大规模的并发点播请求进行分布式处理，使其能适应大型 住宅小区及城域网的应用环境。 随着嵌入式技术的发展与产品的不断推出，与个人电脑服务器的发展，家庭媒 体网络的概念越来越成为一个触手可及的家庭办公、娱乐中心5。一个家庭媒体网络 2 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 基本上是在一个局域网中形成的，以一个多功能多媒体服务器为中心，数字电视、 机顶盒、手机、mp4 等嵌入式设备为客户端组成的多媒体网络。外围播放设备需要 包含解码器、网络连接，以及任何一种显示屏和扬声器。多媒体服务器为网络中的 各种客户端提供多样化的服务， 而 vod 借助多媒体服务器为数字电视或机顶盒提供 的实时点播服务，成为了家庭网络这个概念下的一个主要功能，被赋予新的意义， 称这种基于嵌入式客户端的视频点播系统为嵌入式 vod 系统。 1.3 嵌入式嵌入式 vod 的理论基础与关键技术的理论基础与关键技术 网络视频点播的实现与多媒体、网络研究领域的不断发展息息相关，也是这些 科技领域成果的综合体现。除了传统视频点播系统需要考虑的多媒体技术、网络等 技术之外，以嵌入式系统为客户端的嵌入式vod还需要根据嵌入式的特点着重考虑 以下因素：嵌入式系统相对于个人计算机来说其上的资源较少，例如st公司数字电 视芯片7100使用的st40cpu主频为266mhz，内存包括8mbyte的片上内存和最多 128mbyte的片外内存，相对于个人计算机来说计算能力较小，内存较少。且增加嵌 入式系统的资源所花费的成本相对来说要高，这牵涉到改变芯片的内部架构或者选 用运算速度快的或支持更大内存的芯片。而个人计算机相对于嵌入式系统来说资源 较为丰富。所以针对嵌入式客户端的这种特点，在实现vod功能时需要注意以下两 个方面的问题： 1) 嵌入式客户端中芯片一般包含一到两种主流的硬件媒体解码方式，比较合适 的方式是接收到的流媒体格式与其硬件解码方式相吻合，如果实际点播的媒体压缩 格式与嵌入式客户端芯片中的硬件解码不同，考虑到服务器和客户端两者的资源， 需要在服务器端实现媒体压缩格式的转化。 2) 嵌入式系统的软硬件架构多种多样，为了使嵌入式系统视频点播功能的性能 更好，需要在服务器端针对特有的嵌入式系统做合理的优化。 vod系统所涉及的技术领域非常广泛， 在表1.1中列出了vod技术所涉及的一些 较为关键性的方面，家庭媒体网络属于局域网，它是以集中式服务器为中心、stb 机顶盒等为终端、使用ip协议传输流媒体的网络。与本文研究有较为密切关系的几 3 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 个部分将在第二章介绍。本文的研究重点是局域网vod服务器端多重格式转单一格 式，关于mpeg-2标准与实时网络协议的详细分析将在第二章给出。 表1.1 vod技术要点 分类 内容 系统结构 集中式（单服务器）、分布式（多服务器）6-7 视频引擎 推模式、拉模式8 传输网 catv（hfc）、atm（wdm、sdh）、ip、fddi 接入网 hfc+pstn、xdsl、lan、fttx 服务范围 社区、城域、广域 交互性 nvod9-10、ivod11-12、tvod 视频分发 广播、多播、单播 信源编码 mpeg-1、mpeg-2、real file、mpeg-4 终端 cable modem、计算机、stb机顶盒 标准 davic、dvb 1.4 研究意义与内容安排研究意义与内容安排 家庭媒体网络以家庭媒体服务器为中心，各种嵌入式产品为终端的网络。家庭 媒体服务器主要由高性能的 pc 机构成，为了满足外围多种嵌入式设备的使用需求， 在硬件上采取高配置的前提下，软件能提供的功能至关重要，家庭媒体服务器能否 担当的家庭媒体网络的核心角色，很大程度上取决于软件功能的设计是否能够满足 各式各样外围设备的功能和性能需求。 传统的视频点播的客户端一般是个人计算机，与嵌入式的客户端不同，pc 机倾 向于通用性，使用高频率的通用 cpu，客户端的功能多用软件实现，偶尔会在 pci 插槽上插上专门的硬件解码卡实现多媒体解码功能。而对于嵌入式客户端，例如数 字电视机顶盒，其上的芯片多为专用处理芯片，主频较低，且支持一到两种硬件媒 体解码。用软件解码的方式对于嵌入式的客户端来说不太合适。正是由于嵌入式客 户端的这种特殊性，需要服务器端在设计视频点播服务时考虑到媒体格式的转化， 而相对于实际媒体格式的多样化，所以在服务器端实现多媒体格式到单一媒体数据 4 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 输出的实时转换成为一种实用的功能。本文实现了主流媒体格式转换。实现客户端 点播时，avi 视频实时转化为 mpeg-2 音视频流输出到客户端的 vod 系统。 全文共分六章： 第一章为绪论，主要介绍论文研究背景、vod视频点播技术的发展现状以及本 论文的主要工作和内容安排。 第二章综述嵌入式媒体点播系统用到的主要几种视频格式， 实时mpeg-2的视频 编码原理，用到的网络协议以及rtsp如何实现实时的网络控制。 第三章对嵌入式媒体点播系统服务器端多媒体转换流程的具体实现，包括avi 文件的读取，音视频分流，数据流解码，编码，以及rtsp服务器端的实现与缓冲区 设计。 第四章介绍嵌入式媒体点播系统数字电视客户端的操作系统构建、软件层次结 构与开发环境与rtsp客户端的实现。 第五章为系统的测试。 第六章为全文总结和展望。 5 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 2 嵌入式 vod 相关重要原理分析嵌入式 vod 相关重要原理分析 2.1 嵌入式嵌入式 vod 服务器与客户端架构服务器与客户端架构 vod 服务器端 vod 客户端 1 3 2 1.用 http 协议传送 vod 点播数据 2.用 rtp 协议传送视频、音频、数据 3.用 rtsp 协议控制 rtp 服务器的发送 图 2.1 vod 服务模型 这个模型传递的信息如图 2.1 所示。在这个交互模型中，vod 服务器开启两个 服务13-14：第一个是 http 服务，通过 http 协议，vod 客户端可以向服务器发送点播 信息；第二个是 rtp/rtsp 服务，用来进行视频、音频和数据的传送，协议的层次 如表 2.2 所示。同时，还需要建立一个用户认证的机制来保证信息的安全和个性化服 务的实现。在这个模型中，vod 客户端通过两种协议向服务器传递信息以控制服务 器的行为，但两个协议所实现的功能完全不同，这在下面的模型层次分析中将对这 一点作更详细的说明。 sdp 应用层 rtsp rtp 传输层 tcp udp 网络层 ip 图 2.2 协议层次图 6 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 模型分层描述： 1) 访问传输层 这一层的功能是 ip 数据包的传输与控制。所有的视频、音频数据在服务器进行 rtp 协议的封包之后，再按照 ip 包的格式发送给嵌入式客户端。由这一层来对上层 屏蔽网络细节，它支持有线或无线 ip 网络。 2) 流控制层 这一层中由rtp/rtsp 协议实现相关功能，负责基本的音、视频数据传输功能，包括 流控制和差错纠正。嵌入式客户端可以通过rtcp 协议要求服务器对传输速率进行调整。 3) 应用层 应用层进行点播操作和节目播放管理。 在传统的 vod 系统设计中，包括了 ui 设计和控制协议的制定，在使用 ip 网络 的情况下，需要自己封装消息到 ip 包中，与此对应的服务器端里，需要 vod 服务 器对这些命令进行解析。 利用基于 http 协议的浏览器服务器模型，从而去掉了消息封装和解析的过程。 举例来说，当要像 vod 服务器传送一份定阅列表时，数字电视机顶盒通过表单提交 一份语义信息，具体的封包、发送和解析的过程都留给了浏览器和 http 服务器。通 过使用 http 协议，可以使这一层的功能更加集中。在 ui 的设计上，基于浏览器的 vod 终端解析、显示 html 页面，这些页面实际上只存在于服务器端。 2.2 嵌入式嵌入式 vod 中主要多媒体格式分析中主要多媒体格式分析 2.2.1 avi 格式分析格式分析 avi文件可以同时包含有多个不同类型的数据流，一般的avi文件都包含音频和 视频。avi文件基本格式如下15： riff (avi list ( hdrl avih () list ( strl strh () 7 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 strf () strd(additional header data) ) . . . ) list(movi subchunk|list(rec subchunk1 subchunk2 . . . ) . . . ) idxl ) avi文件都由两个基本list块构成， 即头部信息块和数据块： 头部信息块以“hdrl” 标识，它包含一个avi文件头和若干个描述流信息的子list块list strl。avi文件头包 含了文件大小、文件中帧数、媒体流数目、文件标识(如是否有索引块)等信息。avi 文件中的每个流都对应一个list strl块。在list strl中，stream header是关于流信息的 数据结构，包括流的类型，播放信息等；stream format根据流类型而定，如是视频流 一般是一个bitmapinfo结构，如是音频流则一般为waveformat结构。 数据块以“movi”标识，它由数据子块构成，每个数据子块即为一个视频帧或音 频帧。在有些avi文件中数据块还包含以“rec”标识的子list块，这种“rec”子块指定必 8 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 须同时读入内存的数据块，这些数据块组主要是在计算机从cd-rom读数据时使用。 视频数据和音频数据在数据块内交替存储，具体机制为每x视频帧交替相应的音频 帧，x是个可调参数，最小取值为1，即每一个视频帧交替一个音频帧。x参数越小， avi文件播放时读入内存的数据越少，同理，进行流式传输所需的缓存容量也越小。 在文件的结尾处可以有索引块，由一组aviindex entry结构组成，用以定位 每帧视频数据或音频数据的位置。在avi格式标准中，索引块不是必须的，但由于现 有系统对avi文件的播放必须用到索引块，所以实际上avi文件都有这一项。 avi文件中视频流一般采用mpeg压缩标准。目前avi文件多采用mpeg-1、 mpeg-2、mpeg-4视频压缩16，图像宽度、高度、象素长宽比、帧速率、位速率、 缓冲区大小等重要参数在视频流头部定义，mpeg-1的视频码率约为1.2mb/s， mpeg-2的视频码率根据级别不同而变化，范围为4-80mb/s。mpeg-4视频压缩具有 更好的视频质量并能提供较低码率编码，是今后的视频压缩方向。现在实现mpeg-4 视频压缩的主要为divx4编码。在divx4中提供了三种编码模式:基于稳定码率模式、 基于最佳质量模式和基于目标大小的变换码率模式。对于视频传输来说码率的稳定 性是需要着重考虑的，因此在进行divx4视频编码时，应选用第一种模式。 2.2.2 mpeg-4 文件格式分析文件格式分析 mpeg-4 文件格式是 isma 组织于 1998 年 2 月制定的一种容器格式，是从 quicktime 格式派生而来的，它可以流媒体化并支持众多多媒体的内容：多音轨 （multiple audio） 、视频流（video） 、字幕（subtitlestreams） 、图片（pictures） 、可变 帧率（variable-framerates） 、码率（bitrates） 、采样率（samplerates）等和高级内容 （advanced content） （官方称之为“richmedia”（超媒体）或“bifs”（binary format for scenes） （二进制格式场景） ） 。 在 mpeg-4 文件中，基本的数据单元是原子。每一个原子除了数据外还包含尺 寸和类型信息。尺寸域（size field）是指原子包含的总的字节数，包括尺寸域和类型 域 （type field） 本身。 而类型域指存储在原子中的数据类型， 它往往代表数据的格式。 原子的类型由一个 32 位的整形数来表示，一般是一个四个字符的代码。原子从本质 上是有层次结构，也就是说，一个原子里面可以包含一个或者多个类型不同的原子。 9 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 其文件结构如图 2.3 所示。 trak(video) trak(audio) hint iso file moov other atoms mdat interleaved,time-ordered, video,audio, frames,and hint instractions 图 2.3 mpeg-4 文件结构图 moov 是一个容器对象，只能出现在文件层次上并且在整个文件中只能出现一 次。在 moov 中必须一次出现以下几个对象：一个 mvhd 和至少一个 trak。其中 mvhd 中存放一些和整个文件标识有关的信息，例如文件创建时间，修改时间和整个内容 的长度等； trak 对象是存放各种基本码流以及访问信息的重要容器， 对于各个基本流， 一般都对应存放在一个 trak 中，另外 trak 中也可以存放对另一个 trak 中内容的访问 信息， 这样的 trak 就成为 hint trak， 对应的存放实际媒体内容的 trak 就称 media track。 另外出现在文件层次上的对象还包括 mdat。mdat 中存放实际的媒体数据。 2.3 mpeg-2 视频编码原理视频编码原理 帧顺序 重排 运动估计 dct量化 预测和 帧存储 vlc 编码 buf 反量化 反dct 调整量化 + 码流输出视频帧输入 图 2.4 mpeg-2 编码流程 10 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 图2.4为mpeg-2的编码流程， 为了提高压缩比及图像质量， mpeg-2视频编码采用 运动补偿预测（时间预测+内插）消除时间冗余和不随时间变化的图像细节；采用二 维dct（图像像素+量化传输系数）分解相邻像素，消除观众不可见、不重要的图像 细节；采用熵值编码（已量化参数+编码参数的熵） ，使bit数减少到理论上的最小值。 在本系统中vod要求媒体的格式转化是实时的。这就需要采用优化的mpeg-2 编码，以加速编码过程。以下介绍系统对mpeg-2编码流程中几个部分的优化。 运动估计优化：采用“钻石”搜索法17，“钻石”搜索算法因其搜索模版形状象钻 石而得名。它基于这样一个事实：实际视频序列中相邻两帧的相对运动幅度都比较 小。钻石搜索法以其特殊的搜索窗而能很快搜索到匹配块，因而平均搜索次数更少； 同时由于33的钻石型搜索窗口比33的矩形搜索窗更小，所以精度也更高。是现有 性能最优异的快速搜索算法之一。 钻石搜索算法原理：搜索模版的形状和大小不但影响整个算法的运行速度，而 且也影响它的性能。块匹配的误差在搜索范围内构成误差表明函数，该函数的全局 最小点即对应着最佳运动矢量。由于这个误差表明函数通常不是单调的，所以搜索 窗口太小，就容易陷入局部最优；搜索窗口太大，又容易产生错误的搜索路径，甚 至找不到最佳运动矢量。另外，统计数据表明，视频图象中进行运动估值时，最佳 位置通常在零矢量周围（以搜索窗口中心为圆心，两像素为半径的圆内） 。 dct18采用快速算法，分两种： 1) 利用 fft 实现，但此种方法有不足之处：计算过程涉及到复数的运算。由于 dct 变换前后的数据都是实数，计算过程中引入复数，而一对复数的加法相对于两 对实数的加法，一对复数的乘法相对于四对实数的乘法和两对实数的加法，因此增 加了运算量，也给硬件存储提出了更高要求。 2) 直接在实数域进行dct快速变换。 比前一种方法在计算量与硬件要求都有优化。 2.4 嵌入式嵌入式 vod 网络相关协议网络相关协议 2.4.1 实时传输协议实时传输协议 在ip网络上传输数字音频或视频信号所使用的协议是实时传输协议（rtp： 11 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 real-time transport protocol）19-20。rtp提供两个关键的特性：数据报中的序号及时 间戳。序号允许接收端检测不按顺序的交付或数据丢失，时间戳允许接收端控制视 频回放。因为设计rtp是为了让它传送包括音频和视频等实时数据，所以rtp不强制 统一语法解释，而是每个分组以固定的首部开关，首部中的字段指定如何解释其余 的首部字段以及如何解释有效载荷。 每个数据报以版本（ver）字段中的2位rtp版本开关，当前的版本号为2；6位 序号字段包含数据报的序号，第一个序号的产生是随机的；一些应用程序宣言可靠 的首部扩展，放在固定首部和有效载荷之间。如果应用程序类型允许扩展，则使用x 位指定分组中是否有扩展；对首部中大多数其他字段的解释于指定有效开花类型的7 位有效载荷（ptype）字段，p位指定在有效载荷后是否补零填充，在要求把数据分 配在固定大小的块时使用它；对m位的解释依赖于应用程序，需要标记数据流中的 点（如在发送视频时每帧的头）的应用程序使用它；cc表示参与源id的数量，每个 参与源由32比特构成。 有效载荷类型也影响对时间戳字段的解释。时间戳是随机选择的。标准指定时 间戳会连续增加，甚至在没用检测到信号、没用发送值期间也是如此，准确时间间 隔是由有效载荷类型确定的。 2.4.2 实时传输控制协议实时传输控制协议 实时传输控制协议（rtcp：real-time transport control protocol）是rtp的伴随 协议，它是rtp的一个完整部分，提供需要的控制功能。rtcp允许发送端和接收端 互相传输一系列报告，这些报告包括有关正在传输的数据以及网络性能的额外信息。 rtcp报文封装在udp数据报中，以便进行传输，发送时使用比它们所属的rtp流的 端口大1的协议号。 rtcp使用5个基本报文类型允许发送端和接收端交换有关会话信息。表中列出 了5种rtcp报文类型。 结束报文和应用程序特定报文是最简单的。发送端在停止发数据流时传输一条 报文；应用程序特定报文类型提供了基本功能的扩展，以允许应用程序定义报文类 型。 12 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 接收端周期性地传输接收端报告报文，向发送端通知接收的条件。接收端的报 告很重要，有两个方面的原因。首先，接收端报文允许所有的接收端参与一个会话， 也允许发送端了解其他端的接收；其次，接收端报文允许接收端报文报告的速率， 避免使用过多带宽，淹没其他接收端。 发送端周期性地传输发送端报告报文，提供绝对的时间戳。rtp允许每个数据流 选择一个时间间隔作为自己的时间戳，第一个时间戳是随机选择的。由于绝对时间 戳提供的是接收端必须使多个数据流类型都有单独的数据流，所以发送视频及伴随 的音频需要两个数据流，绝对时间戳信息允许接收端同时播放两个数据流。 除了周期性地传输发送端报告报文以外，发送端还传输源描述报文，提供有关 拥有源站控制权的用户的常规信息。 2.4.3 实时流协议 实时流协议rtsp(real time streaming protocol) 21-22是一个rfc规范，定义在 rfc2325文件中。 它最早是由realnetwork公司、 netscape公司和columbia大学等联合 提出的internet草案。rtsp协议用于建立并控制一个或几个时间同步的连续视频、音 频流的连接。尽管用rtsp交叉传输连续媒体流和控制流是可能的，但通常它并不用 于连续媒体流的传输。也就是说，rtsp充当多媒体服务器的网络远程控制。rtsp 连接没有绑定到tcp连接等传输层连接。在rtsp连接期间，rtsp用户可打开或关闭 多个对服务器的可靠传输连接以发出rtsp请求。此外，也可使用无连接传输协议， 如udp协议。rtsp控制的节目流可以用rtp作为传输协议，但rtsp操作并不依赖用 于携带连续媒体的传输机制。 2.4.4 rtsp 请求和响应消息rtsp 请求和响应消息 1) 请求消息 请求消息用于发出请求。请求消息23-25由请求行、标题行中的各种标题域和实 体主体组成。如图2.5所示。 13 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 sprtsp：/spcrlf :valuecrlf :valuecrlf 主体 . . . . . . 请求行 标题行 图 2.5 rtsp 请求消息格式 sp和if分别代表空格、回车和换行字符。统一资源地址是用户请求访问的 媒体数据的绝对路径。 版本是客户机使用的rtsp协议的iptv机顶盒流媒体 系统研究版本号，现在为rtsp 1.0。方法描述了请求的方法。标题行是可 选的，但客户一般都要在请求消息时插入许多标题行。主体实体在一般情况下很少 使用。 2) 响应消息 服务器接收到客户的rtsp请求消息之后进行分析，将分析和操作结果返回给客 户机。具体的做法是发送一条rtsp响应信息，然后断开相应的tcp连接。响应消息 的格式如图2.6所示。 spstatus codespcrlf :valuecrlf :valuecrlf 主体 . . . . . . 状态行 标题行 图2.6 rtsp响应消息格式 从图中可见，除了状态行之外，响应消息的格式与请求消息的格式相同。状态 行的状态码和短语组合起来表示客户请求所获得的结果。 例如， 14 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 如果请求的媒体文件存放在视频服务器上，而且可发送给客户机，状态码和短语分 别包含“200”和“ok”。实体主体包含有请求消息要获得的额外信息。 2.4.5 rtsp 命令命令 rtsp命令26-27用于客户端请求服务器或者服务器请求客户端执行特定的操作， 如表2.1所示。方向中的c-s代表客户端发送命令到服务器端，s-c代表服务器端发 送命令到客户端。 表2.1 rtsp命令表 命令 方向 要求 含义 describe c-s 推荐 从请求的url中检索媒体对象的描述信息 announce c-s，s-c 可选 请求或更新url的媒体对象的描述 get_paramter c-s，s-c 可选 用于获取url中媒体描述的信息或者用于测试客 户和服务器的连接状况 options c-s，s-c 必须 用于测试服务器实现了哪些功能 pause c-s 推荐 引起流发送的临时终端 play c-s 必须 请求服务器开始以setup方法协商的机制发送数据 record c-s 可选 该方法根据媒体描述初始化数据记录范围 redirect s-c 可选 服务器通知客户端重定向到另一服务器地址 setup c-s 必须 用于决定客户端请求url资源的传输机制 set_paramter c-s，s-c 可选 用于设置请求url中的描述或流的参数值 teardown c-s 必须 客户端请求服务器端停止给定url流发送 2.4.6 rtsp 状态机状态机 rtsp状态机28描述了从rtsp会话初始化开始到会话终止的过程中协议的行为 变化情况。options等一些方法对状态没有影响，所以在这里不讨论它们。 1) 客户端状态机 表2.2 rtsp 客户端状态表 状态 进入该状态的条件 init 当setup请求发出，并等待服务器响应 ready 当接受到setup应答或从playing状态接收到pause应答 playing 当接收到play应答 recording 当接收到record应答 15 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 如表2.2所示，客户端可处于以下状态之一。一般情况下，当客户端在接收到请 求的应答时改变状态。 图2.7表示客户端发送命令请求并接收到成功的应答(2xx)时状态转换的逻辑。 如 果一个命令请求的应答状态码是3xx，则这时客户端进入init状态。如果是4xx，则 客户端的状态不改变。注意在playing和recording状态下，发送setup命令并接收到 成功的应答时，状态不变，只是改变端口。 initplaying recordingready teardown teardown setup record pause pause play tear down play setup setup tear down setup record 图2.7 rtsp客户端状态机 2) 服务器状态机 如表2.3所示，服务器可处于以下状态之一。一般情况下，服务器在接收到命令 请求时改变状态。 表2.3 rtsp服务器状态表 状态 进入该状态的条件 init 服务器启动后，并且没有收到任何setup请求的时候 ready 上一次setup请求是成功的并且应答已发出；播放结束；上一次pause请求 是成功的并且应答已发出 playing 上一次play请求是成功的，应答已发出且媒体数据也已正在传送 recording 服务器正在记录媒体数据 图2.8表示服务器接收到客户端的命令请求，发送成功应答(2xx)后状态转换的 16 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 iptv机顶盒流媒体系统研究逻辑。如果请求结果的状态码是3xx，则服务器进入init 状态。如果是4xx则不改变服务器的状态。可以看到，服务器和客户端的状态转换 逻辑是一致的。 initplaying recordingready teardown teardown setup record pause pause play tear down play setup setup tear down setup record 图2.8 rtsp服务器状态机 如果服务器正发送一个单播节目， 并且这时服务器处于playing或recording状态， 那么在规定的时间间隔内(这个间隔缺省值是1分钟， 服务器可以在应答头中指明具体 的时间间隔值)没有收到客户的信息(这些信息可以是rtcp报文或rtsp请求)，则服 务器可以恢复到init状态并关闭rtsp会话。 如果服务器处于ready状态并且超过1分钟 还没有收到一个rtsp请求，则服务器可以恢复到init状态。注意一些特别的请求倒如 pause)的结果在将来的时间才可能生效，并且服务器的状态也要在合适的时候改 变。 当用户请求的节目结束时， 服务器要从playing或recording状态恢复到ready状态。 和客户端一样，如果没有显式要求在每个点播上都需要发送setup请求，则服务器 可以从ready状态开始，并且服务器也只有两种状态：ready和playing。 2.4.7 会话描述协议会话描述协议 会话描述协议sdp( session description protocol)的目的是为了描述在会话公告、 会话邀请和其他一些形式的多媒体会话应用的初始化时所需的信息。 sdp是一种纯粹 的会话格式描述信息，它不是为一个特定的传输协议而规定的，它可以同实时流协 议rtsp和超文本传输协议http相结合。 17 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 根据sdp的要求，可将会话描述分为以下两种：会话级描述和媒体级描述。会话 级描述适用于整个会话和所有媒体流的细节信息，媒体级会话适用于单个媒体流的 细节信息。媒体描述使得宣布的接收方能够使用所有正确的标记和设置，从会话目 录直接启动正确的媒体工具来加入该会话。 一个宣布是由一个会话级描述部分及其后面的零个或多个媒体级描述部分组 成。当某种媒体被选择时，应该同时选择相应的缺省媒体格式以及缺省地址、传输 协议和端口，并且将它们传送给相应的媒体应用工具。新创建的会话应该具有一个 名字、一段简短的描述、范围、联系信息、启动时间和停止时间。 sdp一般包含以下这些内容：会话的名称和目的、会话开始和结束的时间、会话 的媒体组成以及接收这些媒体所需的信息。这些信息包括接收媒体的地址、端口和 媒体的格式、参加会话所需要的带宽限制、会话负责人的联系方式。sdp是由utf-8 编码的us-ascii字符集。但域和属性的值可以由整个is010646字符集组成。sdp由 一系列的=的文本行组成。总是由一个字符构成并且是大小写敏 感的。是一个依赖于的结构化的文本串，它也是大小写敏感的。在= 符号的两边不允许有空格。一般情况下，是由多个域组成，每个域之间用空 格或其他符号分割。sdp是由一个会话描述层和几个可选的媒体层所组成。其中，会 话描述层的信息适用于整个会话和所有的媒体流，而每个媒体层的描述信息只适用 于单个媒体流。在sdp中，会话层的范围从一个v=的文本行开始，直到遇到第 一个媒体层结束。媒体层的范围是从一个m-的文本行开始，直到下一个媒体层 或整个会话的结束。如果会话层的媒体描述信息没有被相应的媒体层的媒体描述信 息重载，则会话层的媒体描述信息可以适用于所有的媒体。 2.5 嵌入式嵌入式 vod 中中 rtsp 服务器工作原理服务器工作原理 rtsp服务器主要完成对客户端rtsp控制信令的监听、对rtsp会话进行管理、 将rtsp控制信令传递到流服务器和ssrc管理。工作过程首先是请求和登录阶段： rtsp监听模块接收客户端的连接请求，客户端通过各自的rtsp全局控制会话(gcs) 向服务器端请求登录，登录验证成功后客户端再发送点播节目的名称，节目通过验 18 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 证后将进入会话管理阶段。在会话管理阶段，同步源管理器(ssrc)为每一个流请求 生成一个唯一的同步源标识，并负责管理这些ssrc数据的产生、变更和销毁。然后， rtsp会话管理器为每一个用户构造一个会话对象(其中包括ssrc成员)，并把它加入 会话链表。当客户端进行播放、暂停、前进、后退等操作时，服务器通过rtsp信令 传输模块把命令传递到流服务器，并控制盰应的数据流做出相应的动作来完成客户 的要求当客户要退出时，通过全局控制会话gcs发出相应的命令，服务器销毁相 应的会话对象和ssrc对象，并把会话对象从会话链表中删除。 2.6 本章小结本章小结 本章着重介绍了主要的几种多媒体的格式；分析了系统的需求，由于系统需要 快速的实时转换，所以在流程中櫏个环节的处理速度与缓冲区的大小设计至关重要； 考虑到实时点播对时间的要求，在对 mpeg-2 的编码流程中对 mpeg-2 流程中的几 个主要的环节：运动估謡、dct 变换、vlc 编码中使用了优化的算法以加快整体编 码的速度与效率；分析了所用到的网络传输协议 rtp/rtcp，着重分析了 rtsp 的格 式、命令与服务器和客户端的状态机，协议如何实现对服务器客户端双方的实时控 制。rtsp 服务器用于监听 rtsp 请求，处理 rtsp 会话，进而对服务器端发送的多 媒体流进行控制，是客户端用户实时控制点播进程的重要工具， 19 华华 中中 科科 技技 大大 学学 硕硕 士士 学学 位位 论论 文文 3 媒体点播系统服务器端的设计媒体点播系统服务器端的设计 嵌入式媒体播放系统要实现的是嵌入式播放机对服务器上多媒体的实时点 播，在嵌入式客户端的功能菜单中选择 vod 点播功能，这时客户端调用浏览器 并通过 http 协议连接到服务器端，下载可供点播的多媒体节目，并自动弹出到 客户端多媒体菜单中，选中节目并确认后，开始下载并缓冲，当缓冲达到 100 后可以选择播放点播的节目，并且在播放的状态下可以随时暂停和重新播放。由 第一章分析可知，嵌入式媒体点播系统的服务器端与 pc 机的视频点播的区别在 功能方面主要实现的是多种格式到单一媒体压缩格式的转换。以下详细描述了实 现细节。 3.1 多媒体点播服务器端软硬件架构多媒体点播服务器端软硬件架构 嵌入式多媒体点播系统的服务器端由高性能的 pc 组成，选用 core 2 duo 系 列 cpu，主频 2100mhz，总线频率 1066mhz，l2 缓存 2mb*2。主板选用主芯片组： intel p965，cpu 种类 core2，总线频率：fsb 1066mhz，内存为 ddr2，容量 1g 4。硬盘容量为 sata200g。 服务器选择的是有着高性能计算和存储资源的 pc 机，目的是为了使服务器 处理服务器端流程时的速度加快，尽量使得服务器编码再解码的时间竟可能的缩 短。 服务器端操作系统选用 windowsxp。软件开发环境为 visual studio 6.0。 3.2 多媒体点播服务器端的特点