基于android的智能手机视频监控系统的设计与实现.

基于android的智能手机视频监控系统的设计与实现.

2023年7月26日发(作者:)

基于android的手机视频监控系统的设计

移动流媒体技术就是把连续的声音影像信息经过压缩处理后传送到网络服务器上,让终端用户能够在下载的同时观看收听,而不需要等到全部的多媒体文件下载完成就可以即时观看的技术。移动流媒体技术的出现是伴随这移动通信技术的发展和网络音视频技术的进步,其只要是关于流媒体数据从采集到播放整个过程中所需要的核心技术。

移动流媒体数据流具有三个特点:连续性、实时性、时序性。所以流媒体数据流具有严格的前后时序关系。

流媒体传输技术实在FTP/TCP的基础上发展而来的。服务器按照一定的顺序将文件分割成若干个数据分段,然后封装到分组中依次进行传输,客户端接收到分组后重新将其组装起来,最终形成一个与原来一样的完整文件。

流媒体播放技术有优点也有缺点。优点是能够及时传送随时播放,虽然在开始阶段需要一定的时间进行缓冲,但依然能够在实时性要求高的领域具有无可比拟的优势;缺点是由于网络的速率不稳定性,当播放速率大于传输速率时,视频播放将出现停滞,时断时续的现象。 基于android的视频监控系统分为四个模块:依次为采集模块、编码模块、视频传输模块、解码模块、显示模块。如下图所示:

一 视频采集模块

Android摄像头采集的到的视频格式为YUV420格式的视频流。采集模块的实现可以在android的应用层中通过编写代码来实现。

二 编码模块

数字视频编码标准主要由两个标准化组织制定。一个是由国际标准化组织(ISO)和国际电工委员会(IEC)组建的活动图像专家组(MPGE),另一个是国际电信联盟电信标准局(ITU-T)的视频编码专家组(VCEG)。MPEG制定的视频编码标准有MPEG-1,MPEG-2,MPEG-4。ITU一T制定的视频编码标准有H.261和H.263。

为了促进下一代多媒体通信的应用, MPEG和VCEG共同成立了联合视频工作组(JVT),共同开发了视频编码标准H.264。目前,H.264是最先进的视频编码标准。

H.264视频编码标准是目前最新的技术,虽然H.264遵循了原来压缩标准的架构,但是H.264具有一些新的特性,如可变块大小运动补偿,帧内预测编码,多参考帧技术等,所以在性能上有了不小的提升。H.264标准分两层结构,包含网络抽象层(NAL)和视频编码层(VCL)。网络抽象层用于数据打包和传输,编码层负责视频压缩编码,这种分层结构,实现了传输和编码的分离。 由于H.264标准引入了数据分割等抗误码技术,实现了在复杂环境下的使用,可以适应不同网络的传输要求。由于采用高度复杂的实现算法,H.264是目前低码率下压缩率最高的编码标准,在带宽不稳定的无线网络上有着无法比拟的优点。

H.246技术介绍

H.264并不是明确的规定一个编解码器是如何实现的,而是规定了构成编码的比特流的语法、语法元素的语义以及语义元素的解码过程,为不同制造商的编解码器提供兼容性,各个厂商的编码器和解码器在此框架下应能互通,在实现上具有较大的灵活性,而且有利用相互竞争[24,25]。H.264编解码的功能模块跟一般的编解码器大致相同,主要包括预测、变换、量化和熵编码等功能模块,H.264编解码的重要变化主要体现在各个模块的细节上。

H.264是一个总的视频压缩标准,为了适应不同场合的不同应用,H.264规定了不同的档次。其每一个档次规定了不同的语法元素和句法,适合于不同的应用场合。

◆ 基本档次:利用I片P片支持帧内预测和帧间预测编码,支持利用基于上下文的自

适应的变长编码进行熵编码(CAVLC)。只要用于会议电视、可视电话、无线通信等实时视频通信。

◆ 主要档次:支持隔行视频,采用采用加权预测的帧内编码和B片的帧间编码;支

持利用基于上下文的自适应的算术编码(CABAC)。主要用于数字广播电视与数字视频存储等。

◆ 扩展档次:支持码流之间的切换(SP片和SI片),改进误码性能(数据分割)、但是

不支持隔行视频和自适应算术编码(CABAC)。

◆ 高级档次:2004年,视频联合小组又增加了一个高端档次用于支持高精度拓展

FRExt(Fidelity Range Extensions),该拓展支持更高的像素精度。

H.264的4个档次具有不同的功能,每个档次设定不同的参数(如采样速率、编码比特率、图像尺寸等),得到编解码器不同性能的级。

1.H.264编码器

同以往的编码标准,H.264标准没有明确界定的编解码(编码器/解码器的配对),而是定义视频流的编解码方法。 H.264仍采用图像预测和变换编码相结合的编码结构,其编码器本结构如下图所示

:

编码器采用的仍是变换和预测的混合编码法。输入的帧或场Fn以宏块为单位被编码器

处理。首先,按帧内或帧间预测编码的方法进行处理。如果采用帧内预测编码,其预测值PRED(图中用P表示)是由当前片中前面己编码的参考图像经运动补偿(MC)后得出,其中参考图像用Pn一l表示。为了提高预测精度,从而提高压缩比,实际的参考图像可在过去或未来(指显示次序上)已编码解码重建和滤波的帧中进行选择。预测值PRED和当前块相减后,产生一个残差块Dn,经块变换、量化后产生一组量化后的变换系数X,再经嫡编码,与解码所需的一些边信息(如预测模式量化参数、运动矢量等)一起组成一个压缩后的码流,经NAL(网络自适应层)供传输和存储用。为了提供进一步预测用的参考图像,编码器必须有重建图像的功能。因此必须使残差图像经反量化、反变换后得到的D'n。与预测值P相加,得到uF'n。(未经滤波的帧)。为了去除编码解码环路中产生的噪声,为了提高参考帧的图像质量,从而提高压缩图像性能,设置了一个环路滤波器,滤波后的输出F'n。即重建图像可用作参考图像。

2.H.264核心算法

H.264标准的核心思想与现有的其它视频编解码标准一致,也是采用变换和预测的混合编码方法。但是,H.264在算法的实现细节上使用了不同于其他标准的新技术,使得H.264编码性能远远优于其他标准。H.264的核心算法主要包括帧内预测模式、整数变换编码、先进的量化、熵编码和高级运动估计与补偿等。

H.264标准规定了符合H.264标准的档次、级别与码流范围,但是并没有规定具体的编解码算法。H.264标准自2003年公布以后,世界各地的各个组织和研究机构都研发出了自己的H.264编解码器。这些开源代码在支持H.264特性、解码速度和开发难易度等方面不尽相同。目前流行的开源H.264解码器主要有以下4种:

1)JM:JM系列是H.264标准的官方测试源码,由德国HHI(Heinrich HertzIntiut)研究所负责开发,它注重实现H.264标准丰富的功能,并没有专门进行优化。因此该源代码的特点是引入各种新特性提高编解码性能,但是结构冗长、复杂度高。适合进行学术研究但是实用性差。

2)X264:X264是由法国巴黎中心学校的中心研究所的一些学生在网上组织发起的,并由众多视频编解码爱好者共同完成的。其目的是实现实用的H.264编解码器。X264摒弃了一些耗时但是对编码性能提高不是很大的一些功能模块,因此其相比较JM系列而言,在程序结构和算法性能方面有了提高。X264实现了H.264标准的基本档次编码器的基本功能和另外两个档次的部分功能。但是它还没有实现真正的解码功能。

3)T264:T264是由中国视频编码自由组织联合开发的H.264编解码器。T264和X264在程序结构和性能方面有些类似,也是注重实用性,吸收了JM、X264的优点。T264编码输出标准的H.264码流,但是其解码只能解码T264本身的码流。

4)FFmpeg:FFmpeg是一个集录制、转换、音/视频编码解码功能为一体的完整的开源的音频和视频流解决方案。它支持各种音视频标准编解码,还支持各种文件格式(.avi,.mp4,.mkv等)的解析。FFmpeg被许多开源项目采用,比如ffmpeg2theora,VLC,MPlayer,HandBrake,Blender,Google Chrome等。另外,一些著名的播放软件,例如暴风影音、QQ影音和KMPlayer等,里面也采用了FFmpeg的开源代码。FFmpeg是一个非常好的音视频编解码库,支持的标准非常全面,而且解码速度也很快。

比较以上几个开源的解码器可以发现:JM系列代码结构冗长,只考虑引进新特性提高编解码性能,忽视了效率,编码复杂度极高,适合学术研究,没有实际应用价值。X264和JM相比,提高了编码速度,但是其实际上只是一个编码器,还没有真正的解码功能。T264的编解码性能都有了很大提高,但是其职能解码T264本身的码流,具有一定得局限性,通用性不好。通过对以上解码器的研究,针对程序开发上的难以程度、适用场合等做比较后,本次开发决定采用FFmpeg的解码器为原型,经过适当的裁剪优化后进行移植。

FFmpeg是一个集录制、转换、音/视频编码解码功能为一体的完整的开源的音频和视频流解决方案。FFmpeg是基于linux开发的,可以在但多数操作系统中编译和使用。它支持MPEG、DivX、MPEG4、AC3、FLV等40多种编码和AVI、MPEG、OGG、ASF等90多种解码。FFmpeg被许多开源项目采用,比如ffmpeg2theora,VLC,MPlayer,HandBrake,Blender,Google Chrome等。还有DirectShow/VFW的ffdshow(external project)和QuickTime的Perian(external project)也采用了FFmpeg。 FFmpeg的核心项目组成主要包括以下几个部分:

◆ Libavcodec:包含了FFmpeg所需要的音视频编解码器(encoder/decoder)的库,是

FFmpeg的核心部分。为了保证高的可移植性和编解码质量,libavcodec里面好多codec都是从头开发的。本文需要进行移植的H.264解码器就是libavcodec里面的一部分。

◆ Libavformat:包含了各种音视频格式的解析器(demuxer)和产生器(muxer)的库。

用于各种音视频封装格式的生成和解析,包括获取解码所需信息以生成解码上下文结构和读取音视频帧等功能。

◆ libavutil:包含一些公共的工具函数。该库实现了CRC校验码的产生、

最大公约数、整数开方、内存分配、大端小端格式的转换等功能。

◆ libswscale:用于视频场景比例缩放、色彩映射转换等。

◆ libpostproc:用于后期效果处理

一般来说,FFmpeg处理视频的大体流程如下:

1)从test.264文件中打开视频流

2)从视频流中读取包到帧中

3)如果这个帧不完整,跳回到2)

4)对完整帧进行操作

5)跳回到2)

三 传输模块

流媒体传输和控制协议在应用层主要涉及到HTTP,RTSP,RTP和RTCP协议,在传输层有TCP和UDP协议。

HTTP是建立在传输控制协议(TCP)之上的超文本传输协议。TCP/IP协议是专为数据传输而设计的,能够保证传输的可靠性。流媒体的特征要求必须确保数据的实时性和同步性。ITU设计了实时传输(RTP)来解决数据传输的实时性问题。目前,流媒体解决方案主要采取RTP/UDP传输音视频和HTTP/IP传输控制信息。

RTP是在一对一或一对多的情况下针对流媒体数据流工作,不仅能够提供时间信息而且可以保证数据流的同步。通常RTP建立在UDP之上,使用UDP传输数据。RTP本身没有可靠的传送机制,其流量控制和拥塞控制是由实时传输协议(RTCP)来提供的。

RTCP是一个控制协议,负责管理数据传输质量,提供当前应用进程的控制信息和可靠的传输机制。RTP和RTCP共同协作才能完成流媒体的传输和控制。

实时流协议(RTCP)是应用层协议,位于RTP和RTCP协议层之上,通过IP网络传输多媒体数据,在传输机制上采用TCP和RTP完成数据传输。RTSP用于控制实时数据的发送,提供用于音视频流的VCR远程控制功能和用于控制流媒体的播放,暂停,记录等操作。

会话描述协议SDP,SDP是用来描述RTSP,以便说明一个流媒体会话的基本属性,如流媒体的类型,格式,传输带宽,播放时间,缓存容量大小等。通常包含会话信息,媒体信息等。

结合移动视频监控系统对通信实现的特点,本文采用RTP,RTSP,RTCP和HTTP 协议完成视频监控系统的通信和远程控制。

一个最基本的流媒体系统包括编码器,流媒体服务器和客户端播放器三个部分,如 图2.3所示。各个模块之间的数据通信交换都是按照特定的协议。编码器用来将原始的 音视频转换成合适的流媒体格式文件,服务器用来接收和转发编码后的媒体流,客户端 则是负责解码和播放接收到的流媒体数据

流媒体传输有2种方式,一种是顺序流式传输,一种是实时流式传输。

1) 顺序流式传输

顺序流式传输就是顺序下载。用顺序流式传输方法基于标准HTTP或FTP服务器来传输文件,通常容易管理,方便用户的使用。通常不需要特殊的协议。整个下载过程是无损的,能够保证视频的高质量,但是用于网络传输速率的问题,一般需要等待较久的时间。顺序流式传输常用于对视频质量要求较高的场合,对实时性,随机访问性要求较高的场合则不适用。

2) 实时流式传输

实时流式传输能够保证信号带宽与网络连接的匹配,实现实时传送,适合现场直播,支持随机访问,用户可进行快进后退操作。实时流式传输需要传输网络协议和专用的流媒体服务器。相关的流媒体服务器如QuickTime Streaming Server,Windows Media Server等,传输网络协议有RTSP等。由于这些协议与防火墙有关,在使用时一需经过配置。系统设置,管理比顺序流式传输复杂。由于必须匹配连接带宽,在低速连接设备时或者网络拥塞时,会出现丢帧现象,导致视频质量下降。

如图2.4所示的实时传输过程,下面以实时流式传输为例简要说明流媒体传输的基本原理。

1.当某个流媒体服务被用户选择后,Web浏览器和服务器之间使用HTTP/TCP交换控制信息,从流媒体服务器中检索出音视频信息。

服务器从流媒体服务器取出音视频。

3. 终端上的Web浏览器启动客户端程序,使用HTTP从Web服务器检索到的相关数据对客户端程序进行初始化。 4. 客户端程序与流媒体服务器之间使用RTSP来交换传输音视频数据的控制信息。

RTSP实现对流媒体服务器的远程控制,如暂停,快进,回放等

5. 客户端程序通过RTP/UDP协议从流媒体服务器接收到视频流,此时,客户端使用播放程序即可播放视频流。

通过使用RTP/UDP和RTSP压CP两种不同的通信协议,能够切换服务器和不同客 户端之间的通信绑定。

四 解码模块

解码从性质来来讲,其实是编码过程的逆过程。编码采用H.264进行编码,所以该模块也采用H.264进行解码。H.264解码器框图如下所示:由图可知,由解码器的NAL输出一个压缩后的H.264压缩比特流。经熵解码得到量化后的一组变换系数X,再经反量化、反变换,得到残差D'n。利用从该比特流中解码出的头信息,解码器就产生一个预测块PRED,它和编码器中的原始PRED是相同的。当该解码器产生的PRED与残差D,。相加后,就产生uF'n,再经滤波后,最后就得到滤波后的F'n,这个F’。就是最后的解码输出图像。

解码器的整体设计:

解码器的整体设计可以分成两部分,一部分是视频数据的解码部分,主要用C语言来实现,采用Android NDK+C的实现机制。另外一部分是视频的显示部分,主要采用Android提供的组件来实现,采用Android SDK+Java的实现机制。而这两部分的集合,则是通过java提供的jni机制来实现Java和C语言之间的通信。

1. 解码流程

整个解码流程可分为三个功能模块:前段码流处理、H.264解码和后段视频显示。 ● 前段码流处理:主要负责文件的读取,从码流中分隔出NAL然后交给底层进行解码处理.

● H.264解码:整个解码的核心部分,通过本地C语言的实现和解码库对码流数据进行处理,完成H.264解码实现图像重建。

后端视频显示:接收H.264解码模块解码后的视频数据,在android客户端进行显示。

通过分析三个模块的功能可知,H.264解码模块是最耗费资源的。本模块通过移植的H.264解码库来实现解码。另外两个模块则在Android的java层进行实现。H.264视频标准为了更好的适应网络传输的特性,采用了分层设计的思想既视频编码层VCL和网络提取层NAL。H.264的解码部分有包括前端码流处理和H.264解码两个功能模块。其中,前端码流处理主要完成从码流中分割出NAL,这部分功能由java层实现。在java层,采用putStream类来实现码流的读取。读取文件后,我们在java层从H.264码流中分割出Nal,然后交给底层的C来实现实时解码。Nal的分割可以在底层通过C来实现,但是这样多的话,就会出现问题。上层java层每次应该送多少数据给下层呢?如果一次送的太多,底层可能解码出好几帧的数据,但是通知到界面层后,只能显示一帧的数据,这样就造成了丢帧的现象。若是送的数据太少,底层就无法进行实质的解码,可能需要上层等待多次传送后,才能解码出一帧完整的数据通知上层显示。因此,综合考虑之后,决定在java完成Nal的分割。

在android的应用层中编写相应的解码代码来实现H.264的解码,并将解码后的数据传给视频显示模块。

五 显示模块

通过调用android自带的显示器,来显示解码后的本地数据流,从而达到实时视频的显示效果。

发布者:admin,转转请注明出处:http://www.yc00.com/news/1690318021a331792.html

相关推荐

发表回复

评论列表(0条)

  • 暂无评论

联系我们

400-800-8888

在线咨询: QQ交谈

邮件:admin@example.com

工作时间:周一至周五,9:30-18:30,节假日休息

关注微信