基于android设备的音视频实时监控系统的设计与实现

基于android设备的音视频实时监控系统的设计与实现内容摘要：

控系统是目前最为广泛使用的监控系统，然而由于国际上没有统一的标准和接口规范，导致这种系统的实现五花八门、良莠不齐，各个厂家之间 的系统难以互相兼容和对接。 第三代是基于 IP网络的视频监控系统（ IPVS），属于下一代监控系统。 IPVS从视频采集、传输、存储到回放，均采用数字信号，以 IP 网络作为传输媒介，支持远程传输、支持多种分辨率和编码格式。 然而，不管是第一代还是第二代监控系统，传统的视频监控系统都必须要配备专用摄像头、同轴电缆、视频画面分割器、矩阵、切换器、 VCR、 DVR 之类的设备和网络，需要投入大量的硬件设备。 一方面，繁杂的硬件和网络设施导致了传统监控系统的成本普遍偏高，用户实际需求与投入预算往往难以匹配；另一方面，当既有系统容 量需要进行扩展时，由于设备和原网络架构的限制，就会出现很多问题。 而第三代监控系统目前技术尚不成熟，各个厂家推出的所谓第三代监控系统鲜有完全符合规范者，大都不过是厂家为了市场利益而打出的噱头，并不能从根本上解决问题。 北京邮电大学软件工程硕士论文 2 由此可见，为了解决需求与成本的矛盾，为了提高监控系统的的可扩展性，一种廉价、简洁、方便部署，近似第三代监控系统的解决方案亟待推出。 目前国内外也有相关领域的研究，但一般都是止于理论研究与验证阶段，不具实践性（受设备体积、功耗等限制），或没有真正运用于工程实践。 课题任务 本文研究的主要内容 ，是设计一种廉价的、方便部署的、高扩展性的音视频监控系统。 该系统基于 Android 嵌入式设备，以 IP网络作为传输媒介，支持当前主流国际规范和通信协议。 本文的任务是对该监控系统做出详细的需求分析，确定系统架构，给出详细设计方案，对核心技术进行分析，并列举系统实现的关键代码，最后对系统实现进行验证。 作者的主要任务，就是利用攻读硕士研究生课程过程中所学到的知识，结合在企业工作中获得的实际经验，参考各个领域的成熟标准、规范和信息，利用成熟的技术、应用程序框架等，实现上述监控系统，并以论文的形式对该系统进行系统的分 析与讨论。 论文主要内容应包括监控系统相关技术的分析、系统的需求分析与设计过程、系统整体应用架构（包括硬件、软件、网络等）、系统具体实现方式与核心代码、系统应用效果等方面内容。 论文结构 本文共分为六章，内容安排如下： 第一章 引言，介绍本课题的意义、任务、预期目标等。 第二章 相关技术，简要分析了音视频实时监控系统在开发过程中将要涉及到的技术问题，围绕音视频编码、媒体传输协议、媒体传输控制、媒体存储等关键问题，分别对各项技术的现状、特点进行了介绍与对比，列举了部分可选的实现方式或协议。 第三章 需求分析与架构设计，对本文所 论述的监控系统进行需求分析，明确系统应用场景、网络环境要求、性能要求、兼容性与扩展性需求等信息，为系统的详细设计与实现方案提供依据。 此外，文章深入讨论和分析系统的实现方式，通过必要的实验和计算，确定设备形式与配置，并对系统网络拓扑结构进行设计，同时对系统软件、应用软件架构、框架、组件等进行选型。 第四章 详细设计与实现，详细分析设计系统每个技术细节的理论依据、工作原理、应用算法、关键代码等信息，并最终通过软件工程管理手段，将本监控系统完整实现。 北京邮电大学软件工程硕士论文 3 第五章 系统应用，通过对系统在实际工作环境中的应用结果分析，验证系统是否满足需 求分析中提出的各项要求和指标，同时验证基于 Android 设备的音视频实时监控系统设计的合理性、适用，以及对于本文实现方式的肯定。 第六章 结束语，对本文工作进行全面总结，给出本文所取得的成果，指出存在的不足和改进方向。 北京邮电大学软件工程硕士论文 4 第二章 相关技术 本文所研究的音视频实时监控系统，以 Android 嵌入式设备作为受监控端设备，以 IP 网络作为传输媒介，支持当前主流国际规范和通信协议，实现实时的音视频监控和音视频记录与回放。 要实现上述功能，所涉及的技术主要包括以下几点： 音频编码 显然，数字计算机是无法直接处理模拟信号 的。 麦克风拾取的连续的音频信号也是也是一种模拟信号，计算机或其它数字设备必须首先将其转化为数字信号，才能进行下一步处理。 然而，将音频信号进行数字化之后，其信息量是十分巨大的。 以双声道 44100Hz 采样举例，如果每个采样用 16bit 进行存储，如果采样 1分钟，也就是 60秒的话，见下式： 44100 2 16 60 = 84672020bit ≈ 10Mbyte 式（ 21） 如此巨大的数据量，如果通过网络进行传输，需要的网络带宽计算方法如下式所示： 84672020247。 60 = 1411200bps ≈ 式（ 22） 这样的传输带宽要求，对于应用系统的网络环境是比较苛刻的，尤其是在移动通信网络环境下，目前国内尚难以持续稳定的提供这样的带宽。 所谓音频编码，就是利用数学手段，将连续的模拟音频信号转化为数字信息，再通过一定的算法对该数字信息进行编码的过程，该过程通常会通过适当降低音频品质、或减少声音通道等手段，对音频数据进行压缩，以适应诸如剪辑、声效处理、传输、存储、复制、回放等各种应用的需求。 目前广泛应用的音频编码格式 主要有 MP3（ MPEG1 Audio Layer 3）、 AAC（ Advanced Audio Coding）、 AMR（ Adaptive MultiRate）、 、 等 ，这些编码格式各有优点和缺点，分别适用于不同的领域。 本文所讨论的系统采用 编码格式。 编码标准文档已经被 [1]所取代，它是有 ITU（国际电信联盟）制定的一种双速语音编码，分别为 和。 在这两种传输速率下，它分别采用代数码激励线性预测（ ACELP）和多脉冲最大似能量化（ MPMLQ）技术，使得在很小的带宽下能够传输电话语音品质的音频信息。 目前， 编码被广泛应用于 VoIP 服务、视频电话、无绳电话、数字卫北京邮电大学软件工程硕士论文 5 星系统、数电倍增设备 (DCME)、公共交换电话网（ PSTN）、 ISDN 及各种多媒体语音信息产品领域。 视频编码 与音频数据一样，视频数据要通过计算机或其它智能数字设备进行处理，也必须首先量化为数字信息。 在计算机中，视频媒体是以帧的形式存在的，而每一个帧，可以看作是一幅静态的图片，由像素组成。 假设一个以 15fps 录制的视频信息，每帧的分辨率为 800x600，采用 24bit 真彩格式存储，这样的视频录制 1分钟，也就是 60秒，则有： 800 600 24 15 60 = 10368000000bit ≈ 式（ 23） 如果通过网络传输，其带宽应为： 10368000000247。 60 = 172800000bps ≈ 165Mbps 式（ 24） 显然目前几乎根本不可能为单个监控节点分配如此巨大的带宽。 为了解决这一问题，必须采用一定的算法对视频信息进行编码和压缩，使之能够达到当前主流硬件和网络设备能够承受的水平。 所谓视频编码，也是利用数学手段，将连续的视频信号转化为数字信号，并对该信号进行编码，通常是以降低视频分辨率、清晰度、流畅性等为代价 ，对数据进行压缩，实现视频数据量级的降低，以方便对视频信息进行剪辑、存储、传输、复制、回放等操作。 目前广泛应用的视频编码格式 主要包括 MJPEG（ Motion Joint Photographic Experts Group）、 、 AVC（ ， Advanced Video Coding）等 ，它们同样各有优缺点，适用于不同的应用场景。 本文所讨论的系统采用 编码格式。 [2]编码，也是 ITU 制定的一种媒体编码标准，它是专门为低码流应用系统而设计的。 然而 编码是能够适应很 宽的码流范围的，而不仅仅应用于低码流环境。 在很多应用场景下，它被认为是可以完全取代 编码的。 标准的优势主要有如下几点：  使用运动补偿技术和半像素精度；  数据流层次结构的某些部分是可选的，使得其即可适应较低的码流环境，也可以在高码流环境下取得较高的纠错能力；  有四个协商选项来提高性能；  采用无限运动矢量和基于语义的算数编码；  采用预测算法和与 MPEG 中 PB帧类似的帧预测算法；  支持 SubQCIF、 QCIF、 CIF、 4CIF和 16CIF 等 5 种图像格式。 编码最初是为了用于 基于公共 交换电话网和其它基于电路交换的网北京邮电大学软件工程硕士论文 6 络进行视频会议和视频电话 而设计的，但目前更广泛引用于基于 IP 网络和 综合业务数字网 的视频会议系统。 媒体传输协议 本文中所指的传输协议是指用于实现音视频媒体传输过程的网络通信协议，在 OSI 模型中，处于应用层。 常用的媒体传输协议包括 HTTP（超文本传输协议）、MMS（微软媒体服务器）协议、 RTP（实时传输协议）、 MGCP（媒体网关控制协议）等。 在这些协议中，有些适用于文本和图片信息的浏览，有些适合流媒体的传输，有些则更适合运用于电信系统与互联网系统间的媒体互通。 本系统音 视频的传输适宜采用 RTP/RTCP 协议。 RTP/RTCP 协议其实是两个协议，一个是 RTP协议 (实时传输协议 )[3]，另一个是 RTCP协议 (实时控制协议 )。 RTP 协议最初是由 IETF 在 1996年提出的一种用于网络传输的协议，它的目标是保障数据传输的实时性和顺序性，但将数据的完整性置于次要方面。 RTP 协议为数据提供具有实时特征的端对端传送服务，如在 组播 或 单播 网络服务下的交互式视频音频或模拟数据。 应用程序通常在 UDP（用户数据包协议）上运行 RTP 以便使用其多路结点和校验服务。 RTP 协议也可以与其它适合的底层网络或传输协议一起使用，如 TCP（传输控制协议）。 如果底层网络提供 组播 方式，那么 RTP 可以使用该组播表传输数据到多个目的地。 RTP 协议支持承载多种音视频编码格式 [4]，支持动态码率调整和编码格式 的切换，支持动态编码传输。 它对 和 格式的音视频流的封包和传输方法，具有明确的定义 [5]。 RTCP 协议是 RTP 协议的伴生协议，它用于监控服务质量并传送正在进行的会话参与者的相关信息。 利用 RTCP 协议，应用程序可以检测到对端的网络状态、传输带宽、丢包率、延迟等信息，从而动态的调整数据接受或发送的码流大小、编码格式等信息。 此外， RTCP 协议还给出了一种松散的会话管理功能，可以让应用程序简单的控制或监视数据传输参与者的会话状态（如一个发送或接收者的加入或退出等）。 RTP/RTCP 协议被广泛的应 用于视频电话、视频会议系统、实时监控系统等领域。 使用 RTP/RTCP 协议作为监控系统音视频的传输协议，可以保障监控的实时性，同时也可以与几乎所有以相同协议进行媒体传输的其它监控系统、 VoIP系统等进行对接，具有很强的兼容性。 北京邮电大学软件工程硕士论文 7 媒体传输控制协议 媒体传输的过程，需要通过一定的手段进行控制，比如媒体资源如何表示、媒体的编码格式如何、媒体的发送端和接收端如何建立或拆除网络通信等，只有在有效的管理与控制机制下，才能正常工作。 本文中所讲的媒体传输控制协议，就是用于控制媒体的传输过程的网络通信协议，与媒体传输协 议同属于 OSI模型中的应用层。 常用的媒体传输控制协议包括 SIP（会话初始协议）、 RTSP（实时传输流协议）、 ISUP（ ISDN 用户部分）协议等。 本 文 中讨论的流媒体的媒体传输控制，是通过 RTSP 协议来实现的，具体的实现形式，就是构建一个 RTSP 流媒体服务器。 RTSP 流媒体服务器的通信协议栈如图 21 所示，从功能角度出发，在应用层主要分为 RTSP/SDP 会话模块和RTP/RTCP 媒体传输模块两部分。 图 21 RTSP 流媒体服务器通信协议栈 其中 RTSP 和 SDP 两层代表的是 RTSP/SDP 会话模块， RTP 和 RTCP 代表了RTP/RTCP 媒体传输模块。 其中 SDP 层以虚线表示，是因为 SDP 协议数据仅出现在 RTSP 协议的部分数据包中。 RTSP/SDP 也是两个独立而又相关的协议，一个是 RTSP 协议，一个是 SDP 协议。 具体讨论如下： RTSP 协议 RTSP 协议 [6]，中文为“实时流协议”，是用来控制音视频流等流媒体的播放、暂停、停止、录制等行为的协议，一言以蔽之就是用来控制实时数据的传输的。 RTSP 协议具有如下特点：  可扩展性强，可以很容易的加入新的方法和参数；  易实现，通过标准的类 HTTP协议和 MIME解析算法即可实现；  独立于传输， RTSP 协议与媒体传输协议是独立的，因此理论上可以集成任何媒体传输协议；  多服务器支持， RTSP 服务可以与媒体传输服务处于不同的服务器设备，抑郁性能扩展。 RTSP 协议一般需要与 SDP协议配合使用。 北京邮电大学软件工程硕士论文 8 SDP 协议 SDP 协议（会话描述协议） [7]，最初被设计为 SAP（ Session Announcement Protocol，会话发布协议）的一个部件，但之后被广泛的用于与 RTSP、 SIP协议（会话初始协议） [8]协同工作，也可被单独用来。