流媒体实时传输系统的设计与实现(服务器端).doc

江苏技术师范学院毕业设计说明书(论文)流媒体实时传输系统的设计与实现(服务器端)摘 要：随着Internet和多媒体技术的快速发展，网络视频的实时传输成为网络应用的热点之一。H.264 作为新兴的编解码技术带来了技术上的改进，在同等压缩质量情况下，压缩输出码率大约为MPEG-4的二分之一。加之网络带宽的进一步提升，实现网络实时监控技术已趋成熟。本文采用VC+ 6.0开发工具以及套接字编程技术设计与实现一个基于Windows流媒体实时传输系统。该系统通过接收网络摄像机发来的经过H.264编码的视频帧，保存在视频文件中，同时通过NAL单元提取模块在视频帧中搜索NAL单元的起始码从而提取出NAL单元。当NAL单元数据不大于1400B时则将NAL单元封装成单一的RTP包，否则，采用分割NAL单元封装成多个RTP包，其大小不超过IP网络的最大传输单元。经过处理后的NAL单元以RTP包的形式按UDP数据包发往客户端，由客户端实时监控视频。本系统运行可靠，能够正确地接受网络摄像机发来的视频数据，并能正确地发送给客户端，实现客户端实时监控现场。关键词：流媒体，H.264，实时传送协议，NAL单元，网络视频Design and Implementation of Streaming Media Real-time Transmission System (Server)Abstract: With the fast development of Internet and multimedia technology, the network video real-time transmission become one of hot spots of network applications. H.264 as emerging decoding technology, brings in the technical improvement. In the same compression cases, its compression output for original code-rate is about one half of MPEG-4. And further improvement of network bandwidth, network real-time monitoring technology tends to be matured. This paper uses VC+ 6.0 development tool and socket programming technology to design and implement a real-time streaming media transmission system based on Windows . This system receives the H.264 video frames sended by network camera and stores them in the video files .By the Unit extraction module ,it serches start codes in the video frames and extracts NAL Units. when NAL unit data is not bigger than 1400B, makes the NAL unit encapsulate to be a single RTP packet. Otherwise, uses segmentation NAL unit to encapsulate some RTP packets, but its size is not allowed to exceed the maximum transsimision unit of IP network. after dealing, sends them to client through UDP data packet in the form of RTP packet. And client Monitors in real time. This system runs reliably and accurately. It is able to correctly accept video data from network camera , send to client and make client monitor the site in real time.Keywords: Streaming Media，H.264，Real-time Transport Protocol，NAL Unit，Network VideoII目录前言1第1章 流媒体技术概论21.1 流媒体概念21.2 流媒体的特点21.3 多媒体数据网络传输现状31.4 本文主要工作及章节安排3第2章 流媒体传输基础理论52.1 H.264编码简介52.2 UDP协议72.3 RTP协议82.4 H.264视频的传输方法102.5 本章小结13第3章 流媒体实时传输系统服务器端的设计143.1 参数设置模块的设计153.2 接收网络摄像机视频数据模块的设计153.3 保存视频文件模块的设计163.4 NAL单元提取模块的设计173.5 将NAL单元数据封装后发送给客户端模块的设计183.5.1 H.264视频流的RTP设计规则193.5.2 服务器与客户端之间的通信193.5.3 RTP数据包的封装193.6 本章小结22第4章 流媒体实时传输系统服务器端的实现234.1 参数设置模块的实现234.2 接收网络摄像机视频数据模块的实现244.3 保存视频文件模块的实现254.4 NAL单元提取模块的实现264.5 将NAL单元数据封装后发送给客户端模块的设计274.5.1 服务器与客户端之间的通信的实现274.5.2 时间戳的计算274.5.3 NAL单元字节数不大于1400B时的RTP数据包的封装284.5.4 NAL单元字节数大于1400B时的RTP数据包的封装294.6 系统的运行304.7 本章小结32结束语33参考文献34致谢36IV前言视频监控正从传统的安防监控向管理、生产监控发展，并逐步与管理信息系统相结合，达到资源共享，为管理者提供更直观、有效的决策信息。这不仅使人们能以最简便、最逼真、最安全的方式进行远距离实时监控，实现零距离沟通，其在各个领域的广泛应用也有力地推动了整个社会信息化的发展。就目前视频监控系统发展进程来说，它向着前端一体化、视频数字化、监控网络化、系统集成化等方向发展，而数字化是网络化的前提，网络化又是系统集成化的基础。正是在这种背景下，提出网络实时监控系统课题。该课题从功能上可分为三个大模块：第一个模块是网络摄像机，它由DaVinci平台和摄像头构成，DaVinci将摄像头采集到的一帧帧视频图像数据经过H.264压缩算法压缩后按帧发往服务器。第二个模块是服务器模块，它的功能是接收网络摄像机发来的视频帧，并保存在磁盘上，供后期查询视频内容，同时从每一帧中提取NAL单元(Network Abstraction Layer Unit)数据发往客户端进行实时监控。第三个模块是客户端播放器，它的功能是接收服务器端的视频流并用播放器播放，起到实时监控的作用。本课题是网络实时监控系统的一个子系统，主要设计与实现第二个模块，即服务器模块。本文是基于Windows系统设计并实现了流媒体实时传输系统，完成视频的接收与实时传输。所涉及到的理论知识有流媒体技术、视频压缩、RTP实时传输协议以及网络编程等。使用VC+6.0开发工具，利用套接字进行程序设计。第1章 流媒体技术概论1.1 流媒体概念通常意义上的流媒体是指在Internet/Intranet中使用流式传输技术传输的连续时基媒体及其相关技术的统称。实现流媒体的关键技术是流式传输。流媒体传输技术是指把连续的影像和声音信息经过特殊的压缩方式分成一个个压缩包，由音/视频服务器向用户计算机连续、实时地传送。用户可以通过播放器一边下载一边观看，不需要等整个压缩文件下载到本地后才可开始欣赏。实现流式传输有两种方法：实时流式传输（Real-time Streaming）和顺序流式传输（Progressive Streaming)。实时流式传输指保证媒体信号带宽与网络连接配匹，使媒体可被实时观看到。顺序流式传输是顺序下载，在下载文件的同时用户可观看在线媒体，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的部分，顺序流式传输不像实时流式传输在传输期间根据用户连接的速度做调整。实时流式传输特别适合现场事件，也支持随机访问，用户可快进或后退以观看前面或后面的内容。在实际中采用哪种传输方法依赖用户的需求1。1.2 流媒体的特点流媒体具有如下特点：实时传输和实时播放。流媒体使得用户可以立即播放音频和视频，这无论对于获取存储在服务器上的流媒体音频和视频文件还是现场音频和视频流都是很有意义的。如用户可以立即浏览前面一部分视频信息来决定是否继续观看。可以节省大量的存储空间。预先构造的流文件或用实时编码器对现场信息进行编码后得到的现场流比原始信息的数据要小，而且用户不需将所有下载的数据都同时存储在本地存储器上，从而节省了大量的磁盘空间。使传输那些事先不知道或无法知道大小的媒体数据(如网上直播、视频会议等)成为可能。1.3 多媒体数据网络传输现状 国际上一些通用的视频标准的网络传输已得到广泛研究和发展，已制定了一系列的标准。在一般的流式传输中通常都采用了RTP/UDP协议来传输多媒体数据。IETF已经制定了一系列的RTP与特定媒体相结合的标准，如 MPEG-1/2 over RTP，MPEG-4 over RTP， Interleaved Media over RTP， General Audio over RTP， FEC over RTP等。不同的视频编码标准有不同的结构和概念，因此对它们进行RTP封装时所采用的技术就会存在差异甚至是很大的差异。因此，对每种视频编码标准的媒体数据进行RTP封装时，要考虑到它们自身的特性，在提高封装效率的同时，尽量保证。IETF对H.264的RTP封装也已经提出了草案。对于H.264 over RTP现阶段仅有一个Internet草案，还没有正式的标准文档。由于H.264在设计之初就考虑到了网络传输，因此 H.264 具有很好的网络亲和力。在H.264的编码结构中有专门的网络抽象层NAL，因此在一个RTP数据包里可以封装一个或多个NAL单元，视具体的使用场景而定。在H.264 over RTP草案中，提出了三种RTP封装模式：单一NAL模式，非交织模式和交织模式。在单一NAL模式下，只能在一个RTP包中封装一个单一NAL包，该方式兼容ITU-T H.241，适用于低延迟的场合。非交织模式主要适用于不符合H.241建议的低延迟场合，在这种模式下，NAL包要按照NAL单元解码顺序来传输，可以使用单一NAL包，或者不带解码顺序号（Decoding Order Number，DON）的单时间聚合包和不带DON的分割包。交织模式主要用于对端到端延迟要求不严格的场合，它允许把属于一个NAL单元的数据放到多个RTP包中进行传输，这主要用于配合一些错误恢复策略的实施，提高鲁棒性等。除单一NAL包和不带DON的单时间聚合包不能使用外，其他NAL包（大多是带DON的）都可以在交织模式下使用2 。1.4 本文主要工作及章节安排远程视频监控系统由网络摄像机、网络服务器、客户端播放器三部分组成，其结构如图1-1所示。网络摄像机将采集到的每一帧视频图像经过H.264压缩编码后，传输给视频服务器；视频服务器将接收到的帧以NAL单元为单位发送给客户端；客户端网络摄像机网络视频服务器网络客户端图1-1 视频监控系统示意图播放接收到的H.264NAL单元数据。本课题主要设计与实现视频服务器的功能。包括服务器整体架构设计，服务器与客户端的会话交互设计与实现，服务器接收网络摄像机的视频数据，进行RTP封装并发送到客户端。本文主要包括以下内容：(1) 简要介绍本系统中所用到的相关理论知识，分析H.264算法、RTP协议。(2) 服务器的设计与实现，完成的主要功能包括接收网络摄像机的视频流，保存视频流到文件中，将视频比特流分解为NAL单元流，以RTP打包并传输给客户端。本论文章节安排如下: 第1章 对流媒体概念、特点以及多媒体数据传输技术进行简单介绍。第2章 介绍本课题中所用到的通信协议的原理及使用方法。第3章 详细分析视频服务器的需求，并设计流媒体实时传输系统服务器端的功能模块。第4章 介绍流媒体实时传输系统服务器端的实现及运行情况。最后进行总结。第 36 页 共 36 页第2章 流媒体传输基础理论在网络上传输流媒体需要合适的压缩算法对声音/视频数据进行编码，以减轻网络负担。流媒体传输的实现需要合适的传输协议，由于TCP需要较多的开销，故不太适合传输实时数据。在流媒体传输的实现方案中，一般采用HTTP/TCP来传输控制信息，而用RTP/UDP来传输实时声音数据。本文视频图像采用H.264压缩算法编码，应用UDP数据包封装RTP数据包传输给客户端。 2.1 H.264编码简介H.264/AVC是国际电信联盟电信标准化部的VCEG(Video Coding Experts Group) 和国际标准化组织/国际电工委员会的 MPEG(Moving Picture Experts Group)联合成立的“联合视频组”JVT(Joint Video Team)共同制定的视频编码新标准。由于在相同重建图像质量下，H.264相比MPEG-4可以节省约50%的输出码率3。由于H.264采用了许多不同于以往标准中使用的先进技术，所以相对于以往的标准，H.264能获得比H.263和MPEG4更高的压缩性能，有利于用有限的空间存储更多的图像数据；对网络传输具有更好的支持，引入面向数据包编码，有利于将数据打包在网络中传输，支持流媒体服务应用；具有较强的抗误码特性，以适应在噪声干扰大、丢包率高的无线信道中传输；对不同应用的时延要求具有灵活的适应性；编码和解码复杂度具有可扩展性，支持编码和解码复杂度的不等分配和扩展4。H.264作为一种新型的视频压缩标准，对于研究多媒体通信和新一代的网络业务有着重要的意义5。H.264的基本流（elementary stream, ES）的结构分为两层，包括视频编码层VCL(Video Coding Layer)和网络抽象层NAL（Network Abstraction Layer）。VCL负责高效的视频内容表示，而NAL负责以网络所要求的恰当的方式对数据进行打包和传送。引入NAL并使之与VCL分离带来的好处包括两方面：其一、使信号处理和网络传输分离，VCL和NAL可以在不同的处理平台上实现；其二、VCL和NAL分离设计，使得在不同的网络环境内，网关不需要因为网络环境不同而对VCL比特流进行重构和重编码。H.264的基本流由一系列NAL单元（NAL Unit）组成，不同的NAL单元数据量各不相同。当H.264数据流是储存在介质上时，在每个NAL单元前添加起始码，用来指示一个NAL单元的起始和终止位置。起始码有两种，分别是3字节的0x000001和4字节的0x00000001。当一个完整的帧被编为多个片段（slice）时，包含这些编码片的NAL单元使用3字节起始码，其余场合使用4字节的起始码。在这样的机制下，解码器在码流中检测起始码，作为一个NAL单元的起始标识，当检测到下一个起始码时，当前NAL单元结束3。NAL单元是NAL的基本语法结构，它包含一个字节的头信息和一系列来自VCL的称为原始字节序列载荷（raw byte sequence payload，RBSP）的字节流。其中NAL单元头的格式如下图2-1所示。01234567FNRITYPE图2-1 NAL单元头格式禁止位(forbidden_zero_bit)：F，占1 位。值为0表示NAL单元无语法错误。值为 1表示NAL单元头和净负荷中可能包含比特错误或其他语法错误。NAL参考标号(nal_ref_idc)：NRI，占2 位。指示当前NAL的优先级。取值范围为0-3，值越高，表示当前NAL越重要，需要优先受到保护。H.264规定如果当前NAL是属于参考帧的片，或是序列参数集，或是图像参数集这些重要的数据单位时，本句法元素必须大于0。NAL单元类型(nal_unit_type):Type，占5位。标识NAL单元中RBSP数据类型，其中，nal_unit_type为1，2，3，4，5及12的NAL单元称为VCL的NAL单元，其他类型的NAL单元为非VCL的NAL单元。如表2-1所示NAL单元类型。表2-1 H.264规定的NAL单元类型类型编号含义0未规定1非IDR图像中不采用数据划分的片段2非IDR图像中A类数据划分片段3非IDR图像中B类数据划分片段4非IDR图像中C类数据划分片段5IDR图像的片段6补充增强信息 (SEI)7序列参数集（Sps）8图像参数集（Pps）9分割符10序列结束符11流结束符12填充数据13-23保留24-41未规定需要特别指出的是，nal_unit_type值为7和8的NAL单元分别为序列参数集（sps）和图像参数集（pps）。参数集是一组很少改变的，为大量VCL NAL单元提供解码信息的数据。其中序列参数集作用于一系列连续的编码图像，而图像参数集作用于编码视频序列中一个或多个独立的图像。如果解码器没能正确接收到这两个参数集，那么其他NAL单元也是无法解码的。因此它们一般在发送其它NAL单元之前发送，并且使用不同的信道或者更加可靠的传输协议（如TCP）进行传输，也可以重复传输。2.2 UDP协议网络传输的两大基本机制TCP协议和UDP协议。TCP提供了一个完全可靠的面向连接的传输服务，为了在服务器端和客户端之间传送TCP数据，必须首先建立一个TCP连接，并采用三次握手机制来充分保证连接的可靠性。因此，TCP协议是以牺牲连接速度来确保连接的可靠性。在实时流媒体传输中不建议使用TCP协议。UDP协议是面向应用层提供的是无连接的传输服务。这种服务不需要通过三次握手来确保链路的可靠性。由于链路的不可靠性，使得数据传输变得不可靠，也不能够保证数据报按顺序递交。但是，UDP的重要特点是协议的开销小，因此在很多场合中还是相当实用的。在多媒体实时通信中，首先需要解决的问题是应用程序需要选择什么样的传输层协议作为多媒体实时通信的传输方式，很明显，当数据传输的性能必须让位于数据传输的完整性、可控制性和可靠性时TCP协议是当然的选择。但当强调传输性能而不是传输的完整性时，UDP是最好的选择。本课题选择无连接的UDP协议作为传输协议，主要有以下几个原因：1. 多媒体通信中,系统对数据包的丢失率具有一定的容忍度，对传输时延却有很高的要求，系统不希望因为重传数据包而增加网络的传输时延。2. 多媒体通信中，支持多媒体通信的一些实时传输协议，如RTP协议本身已经能够处理流控制和顺序化，所以不需要传输协议进行同样的工作，否则将会降低系统的效率。3. 在多媒体通信中，经常用到组播机制，需要使用UDP这样的无连接的传输层协议，因为UDP能够在实时环境中提供任意方式的通信，它不但能让一对收发方之间进行通信，还可以让单个源向多个接收端进行组播，甚至能允许任意一组发送方向任意一组接收方发送数据。鉴于上述原因，在本课题中使用UDP作为传输层协议使用的，这样，很大程度上减少了因重传造成的时延，同时，也减轻了由此造成的网络带宽损耗，从而提高整个系统的执行效率。2.3 RTP协议RTP协议是IETF在1996年提出的适合实时数据传输协议。RTP协议实际上是由实时传输协议RTP和实时传输控制协议RTCP（Real-time Transport Control Protocol）两部分组成。RTP（Real-time Transport Protocol）是针对用户需要传送实时数据的协议，比如影像、声音、仿真资料等。其提供组播、广播和点对点的传输功能。RTP没有保留资源的能力，亦不保证实时服务的QoS(Quality of Service)。RTCP协议是RTP协议的控制部分，用于实时监控数据传输质量，为系统提供拥塞控制和流控制。RTP 协议在RFC35506中有详细介绍。每一个RTP数据包都由固定包头（Header）和载荷（Payload）两个部分组成，其中包头前12个字节的含义是固定的，而载荷则可以是音频或视频数据。RTP数据包格式如图2-2所示，其中RTP数据包固定头占用12字节，图中每一行占4个字节。开始12个字节出现在每个RTP包中，而CSRC标识符列表仅出现在混频器插入时。表中各项含义如下：1. 版本Version（V）：2位，标识RTP的版本。此协议定义的版本是2(0和1已被使用)。0 0 1234 5 6 78 19 0 1 2 3 4 5 2 36 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1VPXCCMPT(净荷类型)SQ(序列号)TS（时间戳）SSRC（同步源标识符）CSRC（贡献源标识符列表）RTP分组净荷（payload）图2-2 RTP数据包格式2. 填充位Padding（P）:1位。若为1，RTP包尾部就将包含附加的填充字节。填充比特不算作载荷的一部分,填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个RTP包。3. 扩展位Extension（X）：1位。若此位为1，RTP包的头部将附带一个头部扩展。4. CSRC计数（CC）：4位。此数据用来保存CSRC标识符的数量。5. 标记位Maker（M）：1位。用来标记数据流中有意义的事件，如帧边界。比如0代表RTP载荷中的NAL单元是分割传输，1代表RTP载荷是一个完整的NAL单元，或是分割传输的最后一个分片。6. 有效载荷类型Payload Type（PT）：7位。这个字段指出后面的RTP数据属于何种格式，收到RTP分组的应用层就根据此字段指出的类型进行处理。7. 序号Senquence number（SQ）：16位。在第一次RTP会话开始的初始序列号是随机选择的。每发送RTP数据包后，序号就加1，接收方可以利用它来检验是否有丢包的现象，并且依据序号将包按序重组。8. 时间戳Timestamp：32位。时间戳反映了RTP分组中的数据的第一个字节的采样时刻。在一次会话开始时的时间戳初值也是随机选择的。即使没有信号发送，时间戳的数值也要随时间不断的增加。接收端使用时间戳可准确知道应当在什么时间还原哪一个数据块，从而消除传输中的抖动。时间戳还可用来使视频应用中声音和图像同步。9. 同步源标识符SSRC（Synchronization Source）：32位，用以标识同步源，其初始值应随机指定，目的是使得在同一个RTP会话中所有同步源的SSRC值各不相同。10. 贡献源列表CSRC（Contributing Source）list：此列表可有0-15项，每项32位，CSRC列表标识混合载荷数据的多个同步源，标识符的个数由CC字段给出，CSRC标识符由混频器插入，内容是贡献源的SSRC值。在RTP协议中没有具体限定底层网络所能提供的传输服务的类型，通常是将RTP协议与TCP/IP协议栈相结合，运行于UDP 之上，如图2-3所示7。应用层传输层RTP/RTCPTCPUDPIP层接口层图2-3 RTP/RTCP协议在TCP/IP协议栈中的位置2.4 H.264视频的传输方法使用RTP协议传输H.264视频的方法是从H.264视频中剥离出每个NAL单元，在每个NAL单元前添加相应的RTP包头，然后将包含RTP包头和NAL单元的数据包发送出去。下面就从RTP包头和NAL单元两方面分别阐述。完整的RTP固定包头的格式如表2-1所示。下面根据RFC39848给出各个位的具体设置。V：版本号，2位。根据RFC3984，目前使用的RTP 版本号应设为0x10。P：填充位，1 位。当前不使用特殊的加密算法，因此该位设为 0。X：扩展位，1 位。当前固定头后面不跟随头扩展，因此该位也为 0。CC：CSRC 计数，4位。表示跟在 RTP固定包头后面CSRC的数目，对于本文所要实现的基本的流媒体服务器来说，没有用到混合器，该位设为0。M：标记位，1位。如果当前NAL单元为一个接入单元最后的那个NAL单元，那么将M位置 1；或者当前RTP数据包为一个NAL单元的最后的那个编码片时，M位置1。其余情况下M位保持为0。PT：载荷类型，7 位。对于H.264视频格式，当前并没有规定一个默认的PT值。因此选用大于95的值就可以了。此处设为0x60（十进制96）。SQ：序列号，16 位。序号的起始值为随机值，此处设为0，每发送一个RTP数据包，序号值加1。TS：时间戳，32 位。同序列号一样，时间戳的起始值也为随机值，此处设为0。根据RFC3984，与时间戳相应的视频采样时钟频率必须为90000Hz。SSRC：同步源标识符，32位。应该被随机生成SSRC，以使在同一个RTP会话期中没有任何两个同步源具有相同的SSRC识别符。此处仅有一个同步源，因此将其设为0x56781234。对于每一个NAL单元，根据其包含的数据量的不同，其大小也有差异。在IP网络中，当要传输的IP报文大小超过最大传输单元MTU（Maximum Transmission Unit）时就会产生IP分片情况。在以太网环境中可传输的最大IP报文（MTU）的大小为1500字节。如果发送的IP数据包大于MTU，数据包就会被拆开来传送，这样就会产生很多数据包碎片，增加丢包率，降低网络速度。对于视频传输而言，若RTP包大于MTU而由底层协议任意拆包，可能会导致接收端播放器的延时播放甚至无法正常播放。因此对于大于MTU的NAL单元，必须进行拆包处理。RFC3984给出了三种不同的RTP打包方案：1. 单一模式（Single NAL unit Packet）：在一个RTP 包中只封装一个NAL单元，在本文中对于小于1400B的NAL单元便采用这种打包方案。2. 数据包聚合（Aggregation Packet）：在一个RTP包中封装多个NAL单元，对于较小的NAL单元可以采用这种打包方案，从而提高传输效率。3. 数据包分段（Fragmentation Unit）：一个NAL单元封装在多个RTP包中，在本文中，对于大于1400B的NAL单元便采用这种方案进行拆包处理。本课题在实现时采用1和3两种方案，当NAL单元数据不大于1400B时则将NAL单元封装成单一的RTP包，否则，采用分割NAL单元为1400B的多个数据块（最后一块可能不足1400B），分别进行RTP包的封装，以UDP数据包传送给客户端。1. 单NAL单元包传输 本文所使用的单NALU包只包含NAL单元数据。单NAL单元包的RTP净载荷示意图如图2-4所示。由图2-4可以看出，单NAL单元包的结构比较简单，只需直接将提取的NAL单元做为净载荷结构封装进RTP包，并判断是否需要填充数据即可。0 0 1 23 4 5 6 7 1 2 38 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1FNRIType NAL单元数据 可选的RTP填充数据图2-4 单NAL单元包的RTP净载荷示意图2. NAL单元包分段传输 当NAL单元数据尺寸超过1400B时，将分割NAL单元数据，以碎片的形成传输。在以太网环境下，MTU的大小为1500B。本课题将设定每个NAL单元不超过1400B。即NAL单元字节数不大于1400B时单包发送，否则分割成多个数据包发送。原始的NAL单元头部只有一个，分割传输时需要重新处理。本课题采用的分割单元有2个字节的分割单元头部，如图2-5所示分割单元的RTP净载荷示意图。第1个字节称为分割单元指示(F/NRI/Type)，结构与NAL单元头部相同，用来指示该分割单元的优先级、类型。第2个字节称为分割单元头(S/E/R/Type)，用来表示该分割单元是否为一个NAL单元的起始或结束分割单元，以及分割单元的数据类型。0 0 1 23 4 5 6 789101 2 3 4 5 2 36 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1FNRIType SERType 分割NAL单元数据 可选的RTP填充数据图2-5 分割单元的RTP净载荷示意图分割单元指示中的Type值为28表示这是一个分割单元。分割单元头中的S位表示起始位，其值为1时，表示分割的第一块数据；E位表示结束位，其值为1时表示最后一个数据块；R为保留，其值设定为0；Type为该分割单元所属的NAL单元类型。2.5 本章小结流媒体传输的实现方案中，一般采用HTTP/TCP来传输控制信息，而用RTP/UDP来传输声音、视频数据。本课题视频图像采用H.264压缩算法编码，以UDP数据包传输给服务器，再以UDP数据包封装RTP数据包传输给客户端。本章对H.264编码，RTP协议，UDP协议进行了简要的介绍，并重点介绍H.264视频传输方式及本课题采用的RTP打包方式。第3章 流媒体实时传输系统服务器端的设计设置RTP头，将NAL单元封装在RTP数据包中RTP发送服务器端客户端播放合并NAL单元RTP解析接收RTPRTP从UDP数据包中读取视频数据并提取NAL单元图3-1 流媒体传输系统网络摄像机TCP/IP接收网络摄像机发来的UDP数据包一个完整的流媒体传输系统包含网络摄像机、流媒体服务器和客户端三部分。网络摄像机负责将采集到的视频帧经过H.264压缩算法编码后传输给流媒体服务器。流媒体服务器接收到视频帧后，一方面保存在磁盘上，一方面提取视频帧中的NAL单元，分析它的类型，设置相应的RTP包头，封装RTP数据包并发送给客户端。而对于客户端来说，其主要任务则是接收RTP数据包，从RTP包中解析出NAL单元，然后送至解码器进行解码播放。该流媒体传输系统的框架如图3-1所示。根据服务器端实现的功能，可分为以下功能模块：1. 参数设置模块，设置服务器与网络摄像机及客户端的通信参数。2. 接收网络摄像机视频数据模块。3. 保存视频文件模块。4. NAL单元提取模块。5. 将NAL单元数据封装后发送给客户端模块。3.1 参数设置模块的设计1. 流媒体服务器与网络摄像机之间的参数流媒体服务器需要接收网络摄像机之间视频帧，因此需要的参数有：网络摄像机的IP地址及端口号。2. 流媒体服务器与客户端之间的参数流媒体服务器需要将NAL单元数据封装为RTP数据包通过UDP发往客户端，因此需要的参数有：客户端的IP地址及端口号。3. 视频图像需要保存在磁盘上，需要提供磁盘位置参数以及视频文件名。参数设置模块流程图如图3-2所示。图中的参数1、参数2、参数3分别对应上述的1、2、3。图3-2 参数设置模块流程图设置流媒体服务器与网络摄像机之间的参数开始设置参数1Y流媒体服务器与客户端之间的参数设置参数2YNN选择磁盘存放位置参数设置参数3YN结束3.2 接收网络摄像机视频数据模块的设计网络摄像机与服务器之间通过UDP协议通信，网络摄像机将采集到的视频数据经H.264压缩后源源不断地发往服务器。如图3-3为网络摄像机与服务器之间的通信示意图。图3-4 服务器接收网络摄像机的UDP包的处理流程开始接收网络摄像机发来的UDP数据包存入缓冲区中，供其他模块使用创建一个UDP套接字sockfd套接字sockfd与本地IP地址及端口号4598绑定sockfd与摄像机IP地址及端口号5254之间建立连接延迟一段时间图3-3 网络摄像机与服务器之间的通信网络摄像机服务器UDP服务器处理网络摄像机发来的UDP数据包的处理流程如图3-4所示。服务器的端口号4598与网络摄像机的端口号5254之间进行数据通信。3.3 保存视频文件模块的设计网络摄像机以每秒25帧的速度传输视频流，服务器将接收到的视频流保存到磁盘中，以备今后查询观看。由于视频文件很大，需要解决的问题是每隔一定时间长度后另换名存储。本课题采用下列文件名命名SPyymmdd-hhmmss.264，其中，yy、mm、dd分别指年、月、日，hh、mm、ss分别指时、分、秒。当保存视频文件时，取当前系统的时间和日期，例如，当前时间和日期为08:20:10-2011-05-20，则视频文件名为“SP110520082010.264”，每隔一定时间再换一个文件名存储视频文件。视频文件保存模块流程如图3-5所示。ReceiveFrameNum变量是用于记录保存在文件中的视频帧数，根据它的值可计算出视频文件中保存的视频长度，计算公式为：ReceiveFrameNum/25/60分。图3-5 视频文件保存模块流程图开始取当前时间和日期构造文件名,SPyymmdd-hhmmss.264将该视频帧保存在文件中，ReceiveFrameNum+在指定目录下创建该文件，设置接收视频帧计数器ReceiveFrameNum为0.接受到视频帧？NY保存视频文件时间长度到了吗？Y关闭当前文件N延时10ms3.4 NAL单元提取模块的设计本课题采用Davinci技术对摄像头采集的视频图像进行编码，编码算法采用H.264，编码后的H.264视频序列是由一系列NAL单元所构成。一个NAL单元是一个变长的包括某一类型的语义的字节流。在一个视频帧中可由多个NAL单元组