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数据包。4.2数据预处理层本层对本地文件的预处理完全依赖于FFmpeg提供的功能文件解封装功能,而流媒体文件的预处理需将一个或多个RTP数据包整合在一起,这部分技术已经相对成熟,本文将不再复述。本文中流媒体播放器区别于其他普通流媒体播放器的最大特点即为能对外部带有云台的摄像头进行控制,例如焦距、上、下、左、右等方面的设置。所以本文中使用PELCO-D协议作为云台控制协议。中第一字节为同步字也称起始符号,通常都是0xFF。该符号字节用来检测所采用的收发方式正确与否。第二字节填写为目标设备的地址,在命令字1字节中为对摄像头光圈及焦距的控制。在命令字2字节为焦距及变倍控制,其中Bit4,Bit3,Bit2,Bitl为上下左右控制位,最后一个Bit0位总是0。数据1字节中,水平方向速度(00-3F)。数据2字节,垂直方向速度,其数值同数据字节1。校验码字节为前六个字节之和。本文设计的PELCO-D协议文本,最初默认情况下位命令字1、命令字2全部为0,数据字1和数据字2值为20H。通过上层发送的按键消息修改相应命令字1、命令字2的相应位。目前本文中流媒体播放器只提供以上