config.mak文件,这两个文件加起来共有600-700个宏定义,用来描述编译后代码的各个方面参数设置,其中有关于体系架构、编译器、链接库、头文件、版本、编解码器等等相关的宏定义。在这一部分必须要修改关于平台差异方面的定义,比如必须把体系架构改成Android平台的ARMv5TE,这时文件编译的时候指令集就会选择ARM的指令集而不是X86的指令集。这两个文件很重要,以后很多文件都要includeconfig.h这个文件,编译器会根据这个文件而选择性对代码进行编译。2.编译libavutil.a在libavutil建立一个Android.mk的文件,libavutil里的makefile文件需要调用subdir.mak,这个其实就是真正的编译,但是书写在Android.mk下,这个make文件可以不要,但需要直接把对应的源文件引入,标准的makefile是指定.o目标文件,但在Android.mk中需要直接指定.c源文件,Android.mk文件如下所示:LOCAL_PATH:=$(callmy-dir)include$(CLEAR_VARS)LOCAL_MODULE:=avutilLOCAL_SRC_FILES:=adler32.c\……\include$(BUILD_STATIC_LIBRARY)编译时可能会出现很多错误,但这些
问题归结起来大部分都是因为有些头文件没有引入而产生的问题,只要引入相应的头文件后就可以了。比如不识别某些文件的size_t关键字,在该文件includestdio.h后就不报错了,其他类似错误就不一一例举了。其它模块按照相同的方法书写Android.mk文件,移植到Android平台最为本文中播放器的解码模块。
4
各层模块详解
4.1数据获取层
该层完成主要功能为与流媒体服务器协商媒体信息细节,并根据协商结果从服务器端获取流媒体数据,将流媒体数据存入缓冲区,按照本文中缓冲策略将数据包发送给数据预处理
层,其结构图如图2所示:
本文中该层一共启动五个线程,其中一个线程中启动TCP连接,用于RTSP会话协商,并且在RTP数据传输期间,该TCP连接必须一直保留。两个线程分别为接收音频和视频RTP数据的线程,另外两个线程分别为接收以及发送音频和视频的RTCP数据包。
图2数据获取模块结构图
4.2数据预处理层
本层对本地文件的预处理完全依赖于FFmpeg提供的功能文件解封装功能,而流媒体文件的预处理需将一个或多个RTP数据包整合在一起,这部分技术已经相对成熟,本文将不再复述。本文中流媒体播放器区别于其他普通流媒体播放器的最大特点即为能对外部带有云台的摄像头进行控制,例如焦距、上、下、左、右等方面的设置。所以本文中使用PELCO-D协议作为云台控制协议[3]。其协议格式如表1所示:
表1PELCO-D协议格式Byte1
Byte2地址码
Byte3命令字1
Byte4命令字2
Byt