（计算机软件与理论专业论文）嵌入式硬盘录像机（dvr）系统设计及关键技术研究.pdf

摘要 摘要 随着计算机网络技术和多媒体数据压缩技术的不断发展，通过网络传输实 时音视频数据成为可能。如今嵌入式d v r ( d i g i t m d c or c c o r d e r ) 系统不仅仅 提供本地录像的功能，同时集中了网络功能，以达到远程监控的目的。它在安防 监控领域有广泛的应用前景。所以对嵌入式d v r 系统的研究和设计具有实际意 义。 本文研究的嵌入式d v r 系统基于a r m 9 和a r m l i n u x 的软硬件平台，首先论 述了该系统的整体框架( c s 结构) ，接着详细描述了实时音视频网络传输协议、 磁盘管理数据结构、0 s d ( o ns c r e e nd i s p l a y ) 模块等主要功能模块。在音视频 网络传输协议方面，参照实时流传输协议r t s p 以及实时传输协议r t p 的设计思 想，设计了一种易于实现并更符合本系统的音视频网络传输协议；关于磁盘管理 数据结构，针对已有文件系统并不能很好符合需求情况，提出了一种适合音视频 存储的磁盘管理数据结构；0 s d 描述了字符模式和图片模式两种实现方案，并 分别给出了如何实现多语言的方法。 关键字：数字硬盘录像；d v r ：磁盘管理；0 s d ； a b s t r a c t a b s t r a c t w i t ht h ed e v e l o p m e n to fc o m p u t e rn e t w o r ka n dm u l t i m e d i ad a t ac o m p r e s s i o n t e c h n o l o g y , i t i sp o s s i b l et of l a i l s f e rb e t ha u d i oa n dv i d e oo v e rt h ei n t e r n e t a tp r e s e n 4 e m b e d d e dd v r ( d i g i t a lv i d e or e c o r d e r ) s y s t e mp r o v i d e sn o to n l yl o c a lr e c o r d i n g f u n c t i o n b u ta l s on e t w o r kf u n c t i o n t or e a c ht h eg o a lo fr e m o t es u p e r v i s i o n i th a sa w i d ea p p l i c a t i o nf o r e g r o u n di nt h ef i e l do fs e c u r i t ys u p e r v i s o r y s ot h er e s e a r c ha n d d e s i g no ne m b e d d e dd v rs y s t e mh a sa c t u a ls i g n i f i c a n c e n i i sp a p e l * d o e sr e s e a r c ho nt h ee m b e d d e dd v rs y s t e mw h o s es o f t w a r ea n d h a r d w a r ed l a t f o r i l lr e s p e c t i v e l yi sa h n - l i n u xa n da r m 9 f i r s t l y , t h i sp a p e rd e s c r i b e s e n t i r ea r c h i t e c t u r e ( c s ) o ft h ee m b e d d e dd v rs y s t e r n a n dt h e nd e s c r i b e sm a i n f u n c t i o nm o d u l es u c ha st h en e t w o r kp r o t o c o lo ft r a n s f e r r i n ga u d i oa n dv i d e od a t a , h a r dd i s km a n a g c ：m e r i td a t as t r u c t u r e ，o s d ( o ns c r e e nd i s p l a y ) m o d u l e ，a n ds o r e f e r r i n gt ot h er 髑pa n dr t pp r o t o c o i s , w ed e s i g nat r a n s f e r r i n gp r o t o c o lt h a ti s e a s yt oi m p l e m e n ta n di sb e t t e rs u i t a b l ef o rt h i ss y s t e m c o n s i d e r i n gt h ep r e s e n tf i l e s y s t e r n sc a n tm e e tr e q u i r e m e n t s ，w ep r e s e n tah a r dd i s km a n a g e m e n td a t as t r u c t u r e w h i c hi ss u i t a b l ef o rs t o r i n ga u d i oa n dv i d e od a t a 0 s dm o d u l ed e s c r i b e sc h a rp a t t e r n m o d ea n dp i c t u r ei np i c t u r em o d e ，a n d 酉v e st h em u l t i p l el a n g u a g ei m p l e m e n t a t i o n s r e s p e c t i v e l y ， k e y w o r d s ：d i # t a lv i d e or e c o r d e r ；d v r ；h a r dd i s km a n a g e m e n t ；0 s d ； 东南大学学位论文独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我 所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他入已经发表或撰写过的研究成 果，也不包含为获得东南大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同 志对本研究所做的任何贡献均己在论文中作了明确的说明并表示了谢意。 研究生魏埤日期：牢 东南大学学位论文使用授权声明 东南大学、中国科学技术信息研究所、国家图书馆有权保留本人所送交学位论文的复印件和 电子文档，可以采用影印、缩印或其他复制手段保存论文。本人电子文档的内容和纸质论文的内 容相一致。除在保密期内的保密论文外，允许论文被查阅和借阅，可以公布( 包括刊登) 论文的 全部或部分内容。论文的公布( 包括刊登) 授权东南大学研究生院办理。 第一章绪论 第一章绪论 1 1 视频监控系统概述 目前，视频监控系统发展通常分为三个阶段：模拟视频监控系统，本地数字视频监控 系统，网络数字视频监控系统。 ，模拟视频监控系统： 卡带式影象录像机( v c r ，v i d e oc a s s e t t er e c o r d e r ) 为代表的c c t v ( c l o s e dc i r c u i t t e l e v i s i o n ) 闭路电视监控系统该系统特点是音视频的采集、传输、存储均为模拟形式。 基于这种特点，它维护工作量大，查询资料烦琐等等 ，本地数字视频监控系统： 此系统又以数字硬盘录像机( d v r ，d i s t a lv i d e or e c o r d e r ) 为代表，主要特点是音视 频的采集、存储为数字形式，并存储在硬盘上，便于查询和搜索。 d v r 又分基于p c ( p c - b a s e d ) d v r 和基于嵌入式( e m b e d d e d - b a s e d ) d v r 。通常基 于p c 的d v r 软硬件平台为i n t e l x 8 6 系列的处理器和微软的w m d o w s 操作系统，但w m d o w s 不适合每周7 * 2 4 小时工作模式( 可能会死机) ，而且针对w i n d o w s 平台的病毒也繁多，所 以基于p c 的d v r 稳定性差、抗病毒性差。基于嵌入式的d v r 的软硬件平台是a r m 、p o w e r p c 等嵌入式处理器和专用嵌入式操作系统( 如a m l l i n t l x 、u c l i n u x 、v x w o r k 等) 。基于嵌入式的 d v r 在运行速度以及功能上稍逊于基于p c 的d v r ，但它比较稳定和抗病毒能力强，而且 成本低。 ，网络数字视频监控系统： 随着网络技术的发展，兼有网络视频服务器的d v r 也相应产生，主要以嵌入式网络 d v r 方案为主。一般来说，嵌入式网络d v p 中运行嵌入式w e b 服务器，用户通过测览器 直接观看w e b 服务器上的实时视频数据。这种b s ( b r o w s e r s e r v e r ) 方式的优点是用户无 需使用专用软件，仅用浏览器即可。还有一种c s ( c f i e n t s e r v e r ) 方式的，就是用户要安装 客户端软件才能观看服务器上的实时视频数据以及控制服务器，当然可以将客户端软件制成 o c x 控件结合服务器端w e b 服务器，可以实现b s 结构，用户连接服务器端的w e b 服务器 时，w e b 服务器将会提示用户下载控件或自动下载控件，当下载完后，就可以类似原来客户 端软件一样使用了。 网络数字视频监控系统的优势口l ：利用现有的网络资源，网络带宽可复用，无须重复 布线系统扩展能力强，只要有网络的地方增加监控点设备，就可扩展新的监控点。维护费 用低，网络维护由网络提供商维护，前端设备是即插即用、免维护系统。系统功能强大、利 用灵活、全数字化录像方便于保存和检索。在网络中的每一台计算机，只要安装了客户端的 软件，给予相应的权限就可成为监控工作站。 而将下来要描述的嵌入式d v r 就是兼有网络视频服务器的，这类d v r 应用前景越来 越广泛，将来在电信、电力、公安、海关、司法等部门得到应用，对它的设计和研究具有很 好的现实意义。 1 2 论文工作内容和章节组织 1 2 1 开发环境介绍和需要完成的工作 本嵌入式d v r 系统硬件是基于m 的s o c 结构专用m p 4 编解码芯片，内嵌a r m 9 核 ( a r m 9 2 6 e j - s ，处理器以2 4 0m h z 运行，a h b 总线频率为1 2 0m h z ) 。单芯片可以支持4 路c c i r 6 5 6 输入，一路c c i r 6 5 6 输出，四分割器( q u a d ) 功能模块，一个1 d e 接口，一个i c e 东南大学硕士学位论文 接口，一个l o 1 0 0 邶快速以太网接口，两个异步串行接口( u a r t ) ，n o r f l a s h8 m b x 2 ，s d r a m 3 2 岫等。其中i c e 接口用来调试和下载k e r n e l 嵌入式操作系统用的是a n n l i n u x ( 1 i n u x - 2 4 2 1 ) ，主要驱动包括i d e ，m p 4 c n c o d c r 、 m p 4 d e c a d e r 、o s d 、t v o u t ，e t b t 、u a k t 等其中m p 4 e o d 盯、m p 4 d e c o d e r 是提供字 符设备驱动操作m p e 9 4 的编解码。 在此软硬件基础之上，所要做的工作按主要功能分有录像功能、播放功能、o s d 显示功 能、远程监控功能等。 在录像功能中，虽然单芯片只有一个i d e 接口，最多可以接2 块硬盘，但可通过p c i 来扩充 i d e 或s a t a 的硬盘，所以硬盘处理上应该考虑多颗硬盘的环境。还有：硬盘有同时读取和 写入冲突的问题、考虑硬盘的覆盖或不能覆盖下，事件清单满而硬盘空问未满以及事件清单 未满而硬盘空间满的情况。 播放功能中，要能读取硬盘中的事件列表，然后选择某一事件进行播放。还有要能按指 定时间点进行播放。 o s d 显示功能要能够实现多语言的方案，配合系统实现一些相关设置界面设计，如：录 像设置( r e c o r d i n gs e t u p ) 、录像时段设置( r e c o r d i n gs c h e d u l e ) 、侦测设置( s e n s o rs e t u p ) 、视 频参数调节( v i d e o a d j u s t m e n t ) 、硬盘设置( h d ds e t u p ) 、网络设置( l a ns e t u p ) 、系统设 置( s y s t e ms e t u p ) 等界面。 远程监控功能主要是提供客户端和服务器端软件，用户能够利用客户端软件连接服务器 进行网上监控。主要包括音视频的实时传输，m o t i o nd c o c c c 报警设置，云台控制( p 1 z 控制) 等等。 本系统还要实现h t t ps c m 、f i p 盯、d d n sd i c t 、s m t pc l i e n t 、p p p o e 等服务，其中h t t p s c r v e f 是配合客户端软件o c x 的使用，f t ps e r v c r 用来更新服务器端的f u m w a r e ( 如k e r n e l i m a g e ， r a m d i s ki m a g e ) ；d d n sc l i e n t 是支持动态域名，也就是将用户的动态i p 地址映射到一个固定 的域名；s m t pd i e n t 是用来在报警的时候，给相应的人发e m a i l ，不仅是文本信息而且还要 附带一段大概5 10 秒的录像信息；p p p o e 主要是为了支持a d s l 拨号上网。这些服务都运行 在a 帅1 i n u x 上，所以要符合嵌入式l i n u x 的平台的软件来移植 我的工作主要是参与服务器端软件整体架构设计和部分实现，磁盘管理系统数据结构设 计和部分实现，o s d 界面设计和实现，h t t ps e r v e r 等服务移植到a r m - l i n u x 。 1 2 2 各章节内容介绍 本论文主要描述了服务器端软件的设计与实现，同时也描述了远程客户端的部分关键 技术。章节也是按各功能模块来划分，现详细介绍各章节： 。 第一章。绪论主要叙述d v r 系统的发展状况，以及本文的工作。 第二章，服务器端软件的设计与实现。主要叙述了服务器端包含的模块，如磁盘管 理模块、o s d 模块、网络传输模块等。重点描述了服务器端模型、网络传输音视频协 议。 。 第三章，磁盘管理系统模块的设计与实现。在分析当前主流文件系统并不是太适合 我们系统的音视频存储基础，详细描述了我们自定义的磁盘管理数据结构的设计。并对 播放和录像涉及硬盘的操作做了描述。 第四章，o s d 模块的设计与实现。主要叙述了字符模式和图片模式的原理和多语 言实现方案。然后描述了o s d 各界面的设计和实现。 。 第五章，远程客户端的设计与实现。主要叙述了远程客户端软件的设计思想以及某 些关键技术如应用层协议的描述，并且对它的关键技术实现作了简要介绍。 第六章，总结和进一步工作。主要总结了绪论部分谈到的工作内容的完成情况，以 及对本系统的某些关键技术的作了探讨。 2 第二章服务器端软件设计与实现 第二章服务器端软件设计与实现 d v r 系统从整体软件架构来说，一般采用c s ( c f i e n t s e r v e r ) 结构。客户端( c ) 可以 分为音视频的解码，本地存储( a v i 以及原始m p 4 格式存储) 、网络处理( 网络回放，网络 下载等) 、界面设计( g u d 、云台控制等。服务器端( s ) 又可以分为音视频的编解码，本地录 像( 包括磁盘管理) 、网络处理，o s d ( o ns c r e e nd i s p l a y ) 菜单等。 鉴于服务器端包括网络处理，o s d 菜单，还有磁盘管理等，本文将分模块描述它们。 本章将主要描述服务器端总体结构( 重点描述软件) ，以及网络处理模块。而另章节分别详 细描述o s d 菜单模块以及磁盘管理模块。 本系统所采用的软硬件平台分别是：专用m p 4 编解码芯片( 内嵌a r m 9 核 a r m 9 2 6 e j s ) ，嵌入式操作系统采用a r m - l i n u x ( 1 i n u x - 2 4 2 1 ) 。下面将描述基本的硬件和软 件组成。 2 1 服务器端基本硬件结构 d v r 系统服务器端基本硬件结构如图2 - 1 所示册嗍： 图2 - 1d v r 系统服务器端基本硬件结构 该系统单芯片最多可以支持4 路输入，0 s d 和捕获的视频一起叠加后在t v 上显示。视 频压缩采用m p e g 4 标准( i s o i e c1 4 4 9 6 - 2 ，m p 4 e n c o d e r ) ，并将压缩好的数据通过网络发往客 户端，或者存储在本地硬盘上。可以将硬盘上的m p 4 数据解码( m p 4 d e c o d e r ) 在t v 上回放。 2 2 服务器端软件架构 如图2 2 是整个系统软件框架图，其中d v r s e r v e r 包括d v rs e r v e r 应用软件以及底层的 驱动软件( 主要有o s d ，m p 4 e n c o d e r ，m p 4 d e c o d e r ，t v o u t ，i d e 等驱动) 。d v rs e r v e r 应用软 件将是本章重点描述的对象，它负责与客户端软件的交互。客户端分别有本地客户端( 1 0 c a l c l i e n t ) 和远程客户端( r e m o t ec l i e n t ) 。 3 - 东南大学硕士学位论文 i i i r 丽w l 咝ii d v i is e r v e r 图2 - 2 d v r 系统框架图 图2 - 5 就是服务器端软件总体架构。 如图2 - 5 所示，服务器程序设计为多线程来执行不同的任务，如捕获视频线程用来捕 获视频帧；捕获音频线程用来捕获音频帧；o s d 菜单线程主要处理o s d 显示以及作为本地 客户端与服务器主线程进行交互；处理网络连接线程主要处理客户端( 本地和远程) 的连接； 回放线程主要处理录像的回放，本地回放是直接把数据解码后显示在t v 上，而网络回放则 是在网络客户端软件进行解码后播放；而主线程主要处理系统的初始化、响应客户端的请求 ( 包括音视频帧网络传输，本地录像功能音视频帧写入硬盘，移动侦测等等) 。 处理网络连接线程专门用来处理客户端的连接，将每个已连接客户置于【已连接客户 链表】中，并设置s o c k e t 为非阻塞( n o n b l o c k ) 方式。而主线程遍历这个链表，检查是否有 请求或数据，并把这些请求以及相应的客户相关的东西置于【客户请求链表】中。然后分析 这些请求，给出相应的回应。主线程还获取音视频帧，并根据客户端的连接状态来决定是否 把该帧发给该客户，并且还要判断是否有本地录像的请求。主线程就在检查客户端的请求， 分析并响应这些请求，获取音视频帧这几个事项中循环 图2 - 3 【已连接客户链表】显示了只有三个数据结点的情况 图2 4 【客户请求链表】显示了包含无数个数据结点的情况。 4 蓟 第二章服务器端软件设计与实现 搠 初喻船啊官搜颡 盘音砚9 猫姻各自嘴 亿黎翘燃 i f 等) i i 捕获翻殆魄 绷知每黼口，初始 化用户名及密跨 曲酣【硬盘 处理瞬鞫封蝴匿萌磷钱程 绑白啊龇 人 运行划菜韩 融c | m - ，- 口 肚丑熬程之 a 嘞 弋尹i 间魄蓝酊砒 翻n k 处酪嘲奎绫 坤“衄断 并将客户置于 【已j 崮弗e 户链 遍历【已j 鸶辫沪镭翘 等尚煳 表】中 中的客户并静引f 蝴 绒藉善 ) 求置于【客盹割谴虢】 后退出 中，然后分析并露做睡回撇 l 回蝴 获暇音船獭妞秉客 硬趣嘲瞰 朗赫疑沩怙输燃 伛盼是衣地 镕；m 岘鹫赖麓自始远 还剧哟回 程客户端如幕僦 扔 录尉自障犯女蝴琦视 频崎嗣鞠强斟 j 图2 - 5 服务器端简要流程图 2 3 服务器端关键技术分析与实现 2 3 1 服务器模型 2 3 1 - 1 服务器模型概述” 在t c p i p 的使用中，一般来说是客户一服务器的架构，对服务器软件的实现也很多现 成的模型。如：无连接的和面向连接的的服务器，无状态的和有状态的服务器，以及循环和 并发的服务器。 连接性问题涉及到传输协议，一般来说使用t c p 的服务器是面向连接的服务器，而使 用u d p 的服务器则是无连接的服务器。服务器所维护的、关于它与客户正在进行之交互的状 态的信息，称为状态信息( s t a t ei n f o r m a t i o n ) 。没有保留任何状态信息的服务器称为无状 态服务器( s t a t e l e s ss e r v e r ) ，而维护状态信息的服务器称为有状态服务器( s t a t e f u l s e r v e r ) 。循环服务器( i t e r a t i v es e r v e r ，又称迭代服务器) 描述在一个时刻只处理一个请 求的一种服务器实现。并发服务器( c o n c u r r e n ts e r v e r ) 描述在一个时刻可以处理多个请 求的一种服务器，注意不是指下层的实现是否使用了多个并发执行线程，一个线程也可以实 5 东南大学硕士学位论文 现并发，可以并发处理多个请求。 从是否提供并发性以及是否使用面向连接的传输的角度，服务器可以分成四种基本模 型：循环的无连接服务器，循环的面向连接服务器，并发的无连接服务器，并发的面向连接 服务器( 又分为多线程进程并发，单线程并发) 为更清晰了解这写模型，下面分别对这些 服务器举例如下： 循环的无连接服务器( u d p ) ： 如图2 - 6 ，单个线程一次处理一个客户的请求算法：创建u d p 套接字( s o c k e t ) ，绑 定某一端口到套接字( b i n d ) ，重复读取来自客户的请求( r e c v f r o m ) ，给出响应( s e n d t o ) 。 图2 - 6 循环的无连接服务器模型 循环的面向连接服务器( t c p ) ： 算法( 如图2 7 ) ：创建t c p 套接字( s o c k e t ) ，绑定某一端口到套接字( b i n d ) ，把套接 字变换成监听套接字( 1 i s t e n ) ，接受客户连接( a c c e p t ，t c p 使用所谓的三路握手来建立连 接握手完毕a c c e p t 函数返回，返回值为已连接描述字c o n n f d ) ，发送响应( w r i t e ) ，当与 某个特定客户完成交互时，关闭连接( c l o s e ，关闭c o n n f d ，会引发t c p 连接终止序列：每个 方向上发送一个f i n ，每个f i n 又由对端确认，或日四次断连断开连接) 。 图2 7 循环的面向连接服务器模型 并发的无连接服务器( u d p ) ： 算法( 如图2 - 8 ) ：创建u d p 套接字( s o c k e t ) 绑定某一端口到套接字( b i n d ) ，反复 调用r e c v f r o m 接收客户的下一个请求，创建一个新的从线程来处理响应( c r e a t e _ t h r e a d ： w i n d o w s 下有c r e a t e t h r e a d ，1 i n u x 下有p t h r e a dc r e a t e ) 。从线程中按照主线程中的请求以 及套接字来响应客户，处理完该请求后便退出。 创建进程或线程这个操作资源开销还是比较大的，所以对于每一个请求都产生一个进 程或线程的并发的无连接服务器，必须仔细考虑并发性的开销是否会比在速率上的获益大。 一般来说，大多数连接服务器是并发的，而大多数无连接服务器是循环的。只有很少的无连 接服务器采用并发实现。 6 - 第二章服务器端软件设计与实现 s o e k e t o ； t h r e a d _ f u c t i o n b i n d o ； w h i l e 4 1 ) r e c v f r o m o ； c r e a t et h r e a d ( s c n d t o ( ) ； ， r c m m ； t h r e a d _ f t m e t i o n , ) ) ； ) 图2 8 并发的无连接服务器模型 并发的面向连接服务器( t c p ) ： 算法如下：创建t c p 套接字，绑定某一端口到该套接字，把套接字变换成监听套接字 ( 1i s t e n ) ，反复调用a c c e p t 以便接收来自客户的下一个连接请求，并创建新的从线程或进 程来处理响应。从线程中按照主线程传递来的连接请求，并用该连接与客户进行交互，读取 请求并做出响应，在处理完来自客户的所有请求后，从线程就退出。注意在一般情况下，客 户和服务器之间的连接将处理不只一个请求，协议允许客户重复地发送请求和接收响应，而 不必终止这个连接或创建新的连接。如图2 - 9 ，l 是多个单线程进程的模型( 所示为l i n u x 平台) ，2 是一个进程里有多个线程的模型。 l i s t c n f d - - - s o c k e t o ； b i n d ( 1 i s l c n f d ，) ； l i s t e n ( 1 i s t c u f d ，) ； w h i l e ( 1 ) c o n n f d = a c c e p t ( 1 i s t e m l f d ，) ； c r e a t e _ t h r e a d ( ， t h r e a d 自u n c t i o n ，c o n a f d ) ； t h r e a d _ f u n c t i o n ( c o n n f d ) g e a d o w r i t e o ； c l o s e ( c o a a f d ) ； r e t u r n ； ， 2 图2 曲并发的面向连接服务器模型 单线程、并发服务器( 1 p ) 上面介绍了大多数并发的，面向连接的服务器的模型，这种服务器使用了操作系统为 每个连接创建单独的进程或线程，并允许操作系统在线程间用时间分片的方式占用处理器。 这里是说明一个并非显而易见单也能为若干客户提供表面上的并发性的服务器，该服务器的 特点是不用多个控制线程，而是使用单个控制线程。考虑只有一个c p u 情况下。对于多线 程( 或多进程) 的并发服务器，理论上讲服务器依赖操作系统的时间分片机制在多个线程( 或 多个进程) 间共享c p u ，并由此在多个连接间共享c p u 。但如果c p u 足够快地响应客户的 请求，也就是它能在另一个线程收到数据前处理完，那么这种情况下就没有时间片的事情了， c p u 能处理多个客户的请求，而实际上c p u 是顺序执行这些请求的。从此可以看出，用一 个线程也是可以实现并发的，前提是c p u 能够很快处理来自客户的请求，这样即使没有时 7 东南大学硕士学位论文 问片的作用，通过数据的到达驱动，服务器也能处理多个客户的请求。实际上，与使用多线 程或多进程的实现相比，单线程的实现较少需要在线程或进程上下文之间进行切换，因而可 能处理略高一些的工作量 通常编写一个单线程并发服务器的关键是通过在函数s e l e c t 中使用i o 复用，一个服务 器为它必须管理的每一个连接创建一个套接字，然后调用s e l e c t 等待任一连接上数据的到达。 该模型的算法如下( 如图2 - 1 0 ) ：创建套接字，绑定某一端口到该套接字，将套接字加入到描 述字集中( 有读，写和异常三种) ，使用s e l e c t 在已有的套接字上等待f o 。如果最初的套接 字准备就绪，使用a c c e p t 获得下一个连接，并将这个新的连接加入到描述字集中。如果是最 初的套接字以外的某些套接字准备就绪，就使用r e “或r e a d 或得下一个请求，用s e n d 或 w r i t e 发送响应。继续到s e l e c t 上等待f o 。 l i s t e n f d = s o c k e t o ； f o r r a nc o n n e c t e dc l i e n t s ) b i n d ( 1 i s t e n f d ，) ； f d = c l i e n tf d ： l i s t e n ( 1 i s t e n f d ，) ，i f ( f d _ i s s e t ( f d ，& r s e 0 ) m a x f d = l i s t e n f d ；f i f ( r e a d ( f d , k - - 0 ) f d _ z e r o ( & a s e t ) ； 0 0 s e ( f d ) ； f d _ s e t ( 1 i s t e n f d ，& a s e o ；、f d _ c l r ( f d , & a s e o ； w h i j e ( z ) | r s e t = a s e t ；l s e l e c t ( m a x f d + l ，r s e t , ) ； e l s ew r i t e ( m , - - ) ； i f ( f d _ l s s e t ( 1 i s t e n f d ，r s e t ) c o n n f d = a c c e p t ( 1 i s t e n f d ，) ； ) | ) f d _ s e t ( c o n n f d ，& a s e t ) ； i f ( m a x f d c o n n f d ) ) m a x f d = c o m f f d ； 图2 - 1 0 单线程、并发服务器模型 要注意到上述算法的服务器存在一个问题，比如说服务器与客户端交互时，客户端发 送几个字节的数据但在发送换行符前进入睡眠，服务器调用r e a d 读入这几个字节的数据， 然后阻塞于下一个r e a d 调用，以等待该客户的其余数据，服务器只因此客户而被阻塞，不 能为其他客户提供服务。这里必须知道一个概念，当一个服务器在处理多个客户时，它绝对 不能阻塞于只与单个客户相关的某个函数调用( 如上述算法中的r e a d 调用) 否则可能导致 服务器被挂起，拒绝为所有其他客户提供服务，这就是所谓的d o s ( d e n i a l - o f - s e r v i c e ，拒绝 服务) 型攻击可以使用非阻塞的f o 来解决，也就是s e l e c t 加非阻塞i o 。 2 3 1 2d v r 系统服务器模型设计与分析 上一节介绍了各种服务器模型，现在描述一下本d v r 系统服务器模型。当然在设计 d v r 服务器的模型的时候，并没有对每一个模型进行严格测试从而来选择哪一类模型。我 们依赖的是理论分析并结合以前的经验，最终选择了类似于单线程、并发服务器模型( 非阻 塞i o ) ，但又不完全同于该模型。之所以考虑这种模型而没有选择多线程或多进程模型， 是因为考虑到操作系统创建线程或进程的开销比较大，以至于服务器无法承担为每个请求或 每个连接创建一个新线程或进程的重负；而且服务器涉及太多东西，在多个连接中需要共享 信息，这在单个线程情况下能很好的解决。 在叙述服务器端软件架构中，已经粗略了描述了整个架构的设计，以及主线程和一些 从线程的功能。既然服务器软件包含有那么多线程，那是否说明服务器模型就是多线程呢? 这要看从什么角度来分析。刚才说了服务器模型是单线程并发服务器模型，这是说我们是以 主线程来处理客户端的请求并且顺序执行各个客户端的请求，而不是每一个请求或每一个连 8 - 第二章服务器端软件设计与实现 接我们都创建一个线程去处理。现在主要描述本d v r 系统如何在主线程实现并发的。为了 便于对每个已经连接的客户进行处理，可以用链表【已连接客户链表】把它们组织起来，当 然也可以用静态数组。为了便于处理多个来自客户的请求，可以用链表【客户请求链表】来 组织，也可以用静态数组前面说过，单线程实现并发必须保证c p i l 能足够快的解决来自客 户的请求所以主线程在执行每个客户的请求时，不能在一个客户上消耗太多的时间。比如 播放请求，如果这个请求也由主线程来执行的话，势必影响其他客户的响应时间，那也就谈 不上并发。所以主线程只处理一些时耗不太大的任务，而把耗时的任务另启线程处理，这又 有点多线程的意思了，但毕竟由此设计的线程数量不会很多，不会太消耗系统资源。同时避 免d o s 拒绝服务的状况，有必要把连接套接字设置程非阻塞型的。 顺便说一下，为了使服务器端知道客户端是否还在线，客户端必须每隔一定时间向服 务器发送心跳包加以确认( 一般用u d p 协议实现) ，如果长时间没有客户的心跳包，服务器 端就将此客户从【已连接客户链表】除去。心跳包的作用就是检测客户端异常断开。主要原 因是服务器端不能有效的判断客户端是否在线，也就是说，服务器无法区分客户端是长时间 在空闲，还是已经掉线的情况。所以考虑到处理心跳包，服务器同时也是个并发、非连接的 服务器。总的来讲本系统设计的服务器是个单线程、并发多协议服务器( t c p ，u d p ) 2 3 2 实时音视频传输协议 2 3 2 1 流媒体传输协议概述乜1 1 嘲 目前网络传输音视频等多媒体信息主要有两种方式：下载和流式传输。由于音视频等 多媒体信息数据量大，再加上网络带宽的限制，下载传输方式常常要花数分钟甚至数小时 而流式传输方式下，流式媒体在播放前不需要下载整个文件，只将开始部分内容存入内存， 流式媒体的数据流边下载边播放。前者需要将数据下载到本地才能播放，而后者可以向计算 机用户连续、实时传送数据流，用户不需要等所有数据下载完毕才能播放，而只需经过几秒 或十几秒的启动延时即可进行观看，当声音视频等在用户的机器上播放时，文件的剩余部分 还会从服务器上继续下载。 有人曾经对流媒体做了一个比较形象的比喻，那就是把流式传输音视频比作用桶接水 的过程，这里水就是音视频，桶的容量就是音视频的整个大小服务器发送音视频比作水龙 头传送水，用水比作客户端播放下载传输方式规定只有桶中水满后，才可以用水，而流式 传输方式是要开始等待直到桶中有部分水时就可以使用，当然用水是否连续那就看用水速度 和进水速度以及开始的部分水的容量来决定。说明：需要部分水的原因就是因为进水速度是 个未知量，可能慢也可能很快，而用水速度基本稳定，所以用这部分水来缓解用水速度受进 水速度的影响，也即尽量保证用水速度不变。 实现流式传输有两种方法：实时流式传输( r e a l t i m es t r e a m i n g ) 和顺序流式传输 ( p r o g r e s s i v es t r e a m i n g ) 。顺序式流式传输，如流h 1 _ r p 协议流式传输( 与标准h t t p 协议不同，它使用特定的p r a g m 参数值、数据类型值和包前缀) ，在下载文件的同时用户可 观看在线媒体，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的前头部 分。顺序流式传输不适合长片段和有随机访问要求的视频，如：讲座，演示等。它也不支持 现场广播，严格说来，它是一种点播技术。实时流式传输，如r t s p 流式传输，实时传送， 特别适合现场事件，也支持随机访问，用户可快进或后退以观看前面或后面的内容。 实时流协议( r t s p ，r e a m m e s t r e a m i n g p r o t o c 0 1 ) 是由r e a l n e t w o r k s 和n e t s c a l p e 共同 提出的，该协议定义了一对多应用程序如何有效地通过i p 网络传送多媒体数据。此协议在 语法和操作上类似h t l r 但两者也有不同，如r t s p 引入了新的方法( m e t h o d ) 、r t s p 服 务器和客户端能相互发送请求，r t s p 在任何情况下，必须保持一定状态，以便在请求确认后 的很长时间内，仍可设置参数，控制媒体流等等。r t s p 是个应用层协议，用来控制具有实时 - 9 东南大学硕士学位论文 特性的数据的传送。 实时传输协议( r t p ，r e a l - t i m et r a n s p o r tp r o t o c 0 1 ) 是用于i n t e r n e t 上针对多媒 体数据流的一种传输协议。传送音视频数据通常都会采用基于u d p 的r t p 传输，r t p 为数据流提供时间信息和实现流同步。但r t p 本身并不能为按顺序传送数据包提供可 靠的传送机制，也不提供流量控制或拥塞控制，它依靠r t c p 提供这些服务。 r t p 控制协议( r t c p ，r e a l - t i m et r a n s p o r tc o n t r o lp r o t o c 0 1 ) 通过周期性交换两端实 体的控制信息，为会话两端实体提供质量反馈信息，这种反馈信息可以用于检测并纠正实时 传输中存在的问题。 通常r t s p 协议通过和r t p 、r t c p 等协议协同工作，实现流媒体数据的实时传输，具 有很好的应用性能，本协议也可以独立工作，实现基于t c p 或者u d p 协议的实时流的传输。 2 3 2 2 传输音视频数据包协议设计与实现 以上介绍了r t s p ，r t p 等协议，我们系统并没有直接应用这些协议，但在设计自定义 的应用层协议时参考过这些协议的设计思想。至于为什么不直接用这些协议，原因有如下几 种：协议实现难易( 包括服务器以及客户端) ，系统针对性等。因为r t s p ，r t p 等协议具 有一般性，它们很多字段在我们的系统中并不会用到。而且要实现r t s p 协议的服务器，并 非短时间内能完成为此，我们自己定义应用层协议来传输音视频数据，详细设计如下： 对于音视频的网络传输，原则是控制信息( 需精确性收发) 采用t c p 来传输，而对于数 据精确性不太高的媒体数据采用u d p 传输。实时数据的传输不用t c p 的理由很明显那是因 为t c p 等待确认应答及重新传输丢失的数据分组的机制使得实时数据的传输变得很长，并 且不可预测。但直接用u d p ，不能检测分组丢失、错序。所以只能在应用层协议加上这些 功能，比如加序列号( 每传输一个分组，该序列号加1 ) 如图2 1 1 是应用层音视频的传输流。 i 坚i ! ! 垡l 竺竺! 竺! i 图2 - 1 1 应用层音视频传输流 应用层传输包( a vp a c k e t ) 主要含有h e a d e r 和d a t a ，其中h e a d e r 的各字段的含义分别 如下： pc l a s s ：指定哪种类型( 数据、命令等) 的数据包； t y p e ；区分音频或者视频。便于统计音视频包的帧号( f r a m e _ i d ) 和序列号( s e q _ i d ) ： c hi d ：指定从哪个通道的数据；我们的系统现在单芯片只支持4 路，但协议设计时最 多支持1 6 路。 f r a m ei d ：每发出一帧，该字段值加一；确定发送了多少帧数据，当然要区分音频还是 视频帧，也即音视频帧独立计算。 f r a g m e n t s e qi d ：每发一个数据包，该字段值加一；为了确定分组顺序，检测分组丢失，必须对 分组进行编号，但传输层u d p 并不支持序号功能，所以在应用层协议需加上这一项功能。 音视频包类似f r a m e 也独立计算。_id l e n ：包含此头的数据包长度。 还要说明的是为了正确还原音频或视频信号，必须保持采样和播放之间的同步关系。这 1 0 第二章服务器端软件设计与实现 中同步关系通过每帧数据的携带的时间戳来实现。而且时间戳也可以用来测量每一帧数据的 到达的时延。所以d a m 域不只是音视频数据，也包括相关数据( 其中就有f r a m e _ t i m e ) ，它 与硬盘存储的音视频包格式一样( 详见磁盘管理系统的描述) d a t a 域设计成跟硬盘存储 的音视频包格式一样是为了方便，因为如果不同的话，就会作一些转换，给编程人员带来麻 烦，而且这些转换也会花时间，前面也说过，尽量不要给主线程说增加额外负担。 其中d a 纽部分，因为视频帧大小( n m p 9 4 帧) 可能比较大，涉及到视频的数据打包算法， 几种方案如下： 可以采用固定的的大小对视频流打包，但压缩后的图像数据大小并不固定，这种包可能 包含两帧图像部分数据，使包与包之间存在依赖关系，并且如果此包丢失会影响此两帧图像。 我们系统采用了按帧来进行打包，不过每一帧数据的大小并不固定，如果当前帧数据比 较大，超过m t u ( 网络最大传输单元) ，则要考虑把包拆分成多包进行传送。如果一帧数据 分包后，剩余部分比较少，也不再与另- - , j , 数据帧图像组成一包( 不跨帧打包) 。所以，如 果一帧数据比较小的话，d a t a 将是完整的一帧，如果一帧被拆分多包的话，那么d a t a 将是