(hanchao3c Android开发者论坛原创,转载请注明)
本文为个人总结,不代表官方观点。第一部分 OpenCore概述
OpenCore的另外一个常用的称呼是PacketVideo,它是Android的多媒体核心。事实上,PacketVideo是一家公司的名称,而OpenCore是这套多媒体框架的软件层的名称。在Android的开发者中间,二者的含义基本相同。对比Android的其它程序库,OpenCore的代码非常庞大,它是一个基于C++的实现,定义了全功能的操作系统移植层,各种基本的功能均被封装成类的形式,各层次之间的接口多使用继承等方式。
OpenCore是一个多媒体的框架,从宏观上来看,它主要包含了两大方面的内容:
PVPlayer和PVAuthor以SDK的形式提供给开发者,可以在这个SDK之上构建多种应用程序和服务。在移动终端中常常使用的多媒体应用程序,例如媒体播放器、照相机、录像机、录音机等等。
为了更好的组织整体的架构,OpenCore在软件层次在宏观上分成几个层次:
事实上,OpenCore中包含的内容非常多:从播放的角度,PVPlayer的输入的(Source)是文件或者网络媒体流,输出(Sink)是音频视频的输出设备,其基本功能包含了媒体流控制、文件解析、音频视频流的解码(Decode)等方面的内容。除了从文件中播放媒体文件之外,还包含了与网络相关的RTSP流(Real Time Stream Protocol,实时流协议)。在媒体流记录的方面,PVAuthor的输入的(Source)是照相机、麦克风等设备,输出(Sink)是各种文件,包含了流的同步、音频视频流的编码(Encode)以及文件的写入等功能。
在使用OpenCore的SDK的时候,有可能需要在应用程序层实现一个适配器(Adaptor),然后在适配器之上实现具体的功能,对于PVMF的NODE也可以基于通用的接口,在上层实现,以插件的形式使用。
第二部分 OpenCore的代码结构
以开源Android的代码为例,OpenCore的代码在以下目录中:external/opencore/。这个目录是OpenCore的根目录,其中包含的子目录如下所示:
在external/opencore/目录中还有2个文件,如下所示:
在external/opencore/的各个子文件夹中包含了众多的Android.mk文件,它们之间还存在着“递归”的关系。例如根目录下的Android.mk,就包含了如下的内容片断:
include $(PV_TOP)/pvcommon/Android.mk
include $(PV_TOP)/pvplayer/Android.mk
include $(PV_TOP)/pvauthor/Android.mk
这表示了要引用pvcommon,pvplayer和pvauthor等文件夹下面的Android.mk文件。
external/opencore/的各个Android.mk文件可以按照排列组合进行使用,将几个Android.mk内容合并在一个库当中。
1.库的层次关系:在Android的开源版本中编译出来的内容,OpenCore编译出来的各个库如下所示:
这些库的层次关系如下图所示:
OpenCore的各个库之间具有如下的关系:
libopencorecommon.so是所有的库的依赖库,提供了公共的功能;
libopencoreplayer.so和libopencoreauthor.so是两个并立的库,分别用于回放和记录,而且这两个库是OpenCore对外的接口库;
libopencorenet_support.so提供网络支持的功能;
一些功能以插件(Plug-In)的方式放入Player中使用,每个功能使用两个库,一个实现具体功能,一个用于注册。
libopencorecommon.so是整个OpenCore的核心库,它的编译控制的文件的路径为pvcommon/Android.mk,这个文件使用递归的方式寻找子文件:
include $(BUILD_SHARED_LIBRARY)
include $(PV_TOP)//oscl/oscl/osclbase/Android.mk
include $(PV_TOP)//oscl/oscl/osclerror/Android.mk
include $(PV_TOP)//oscl/oscl/osclmemory/Android.mk
include $(PV_TOP)//oscl/oscl/osclutil/Android.mk
include $(PV_TOP)//oscl/pvlogger/Android.mk
include $(PV_TOP)//oscl/oscl/osclproc/Android.mk
include $(PV_TOP)//oscl/oscl/osclio/Android.mk
include $(PV_TOP)//oscl/oscl/osclregcli/Android.mk
include $(PV_TOP)//oscl/oscl/osclregserv/Android.mk
include $(PV_TOP)//oscl/unit_test/Android.mk
include $(PV_TOP)//oscl/oscl/oscllib/Android.mk
include $(PV_TOP)//pvmi/pvmf/Android.mk
include $(PV_TOP)//baselibs/pv_mime_utils/Android.mk
include $(PV_TOP)//nodes/pvfileoutputnode/Android.mk
include $(PV_TOP)//baselibs/media_data_structures/Android.mk
include $(PV_TOP)//baselibs/threadsafe_callback_ao/Android.mk
include $(PV_TOP)//codecs_v2/utilities/colorconvert/Android.mk
include $(PV_TOP)//codecs_v2/audio/gsm_amr/amr_nb/common/Android.mk
include $(PV_TOP)//codecs_v2/video/avc_h264/common/Android.mk
这些被包含的Android.mk文件真正指定需要编译的文件,这些文件在Android.mk的目录及其子目录中。事实上,在libopencorecommon.so库中包含了以下内容:
从库的结构中可以看出,最终生成库的结构与OpenCore的层次关系并非完全重合。libopencorecommon.so库中就包含了底层的OSCL的内容、PVMF的框架以及Node和编解码的工具。
libopencoreplayer.so是用于播放的功能库,它的编译控制的文件的路径为pvplayer/Android.mk,它包含了以下的内容:
include $(BUILD_SHARED_LIBRARY)
include $(PV_TOP)//engines/player/Android.mk
include $(PV_TOP)//codecs_v2/audio/aac/dec/util/getactualaacconfig/Android.mk
include $(PV_TOP)//codecs_v2/video/avc_h264/dec/Android.mk
include $(PV_TOP)//codecs_v2/audio/aac/dec/Android.mk
include $(PV_TOP)//codecs_v2/audio/gsm_amr/amr_nb/dec/Android.mk
include $(PV_TOP)//codecs_v2/audio/gsm_amr/amr_wb/dec/Android.mk
include $(PV_TOP)//codecs_v2/audio/gsm_amr/common/dec/Android.mk
include $(PV_TOP)//codecs_v2/audio/mp3/dec/Android.mk
include $(PV_TOP)//codecs_v2/utilities/m4v_config_parser/Android.mk
include $(PV_TOP)//codecs_v2/utilities/pv_video_config_parser/Android.mk
include $(PV_TOP)//codecs_v2/omx/omx_common/Android.mk
include $(PV_TOP)//codecs_v2/omx/omx_queue/Android.mk
include $(PV_TOP)//codecs_v2/omx/omx_h264/Android.mk
include $(PV_TOP)//codecs_v2/omx/omx_aac/Android.mk
include $(PV_TOP)//codecs_v2/omx/omx_amr/Android.mk
include $(PV_TOP)//codecs_v2/omx/omx_mp3/Android.mk
include $(PV_TOP)//codecs_v2/omx/factories/omx_m4v_factory/Android.mk
include $(PV_TOP)//codecs_v2/omx/omx_proxy/Android.mk
include $(PV_TOP)//nodes/common/Android.mk
include $(PV_TOP)//pvmi/content_policy_manager/Android.mk
include $(PV_TOP)//pvmi/content_policy_manager/plugins/oma1/passthru/Android.mk
include $(PV_TOP)//pvmi/content_policy_manager/plugins/common/Android.mk
include $(PV_TOP)//pvmi/media_io/pvmiofileoutput/Android.mk
include $(PV_TOP)//fileformats/common/parser/Android.mk
include $(PV_TOP)//fileformats/id3parcom/Android.mk
include $(PV_TOP)//fileformats/rawgsmamr/parser/Android.mk
include $(PV_TOP)//fileformats/mp3/parser/Android.mk
include $(PV_TOP)//fileformats/mp4/parser/Android.mk
include $(PV_TOP)//fileformats/rawaac/parser/Android.mk
include $(PV_TOP)//fileformats/wav/parser/Android.mk
include $(PV_TOP)//nodes/pvaacffparsernode/Android.mk
include $(PV_TOP)//nodes/pvmp3ffparsernode/Android.mk
include $(PV_TOP)//nodes/pvamrffparsernode/Android.mk
include $(PV_TOP)//nodes/pvmediaoutputnode/Android.mk
include $(PV_TOP)//nodes/pvomxvideodecnode/Android.mk
include $(PV_TOP)//nodes/pvomxaudiodecnode/Android.mk
include $(PV_TOP)//nodes/pvwavffparsernode/Android.mk
include $(PV_TOP)//pvmi/recognizer/Android.mk
include $(PV_TOP)//pvmi/recognizer/plugins/pvamrffrecognizer/Android.mk
include $(PV_TOP)//pvmi/recognizer/plugins/pvmp3ffrecognizer/Android.mk
include $(PV_TOP)//pvmi/recognizer/plugins/pvwavffrecognizer/Android.mk
include $(PV_TOP)//engines/common/Android.mk
include $(PV_TOP)//engines/adapters/player/framemetadatautility/Android.mk
include $(PV_TOP)//protocols/rtp_payload_parser/util/Android.mk
include $(PV_TOP)//android/Android.mk
include $(PV_TOP)//android/drm/oma1/Android.mk
include $(PV_TOP)//tools_v2/build/modules/linux_rtsp/core/Android.mk
include $(PV_TOP)//tools_v2/build/modules/linux_rtsp/node_registry/Android.mk
include $(PV_TOP)//tools_v2/build/modules/linux_net_support/core/Android.mk
include $(PV_TOP)//tools_v2/build/modules/linux_download/core/Android.mk
include $(PV_TOP)//tools_v2/build/modules/linux_download/node_registry/Android.mk
include $(PV_TOP)//tools_v2/build/modules/linux_mp4/core/Android.mk
include $(PV_TOP)//tools_v2/build/modules/linux_mp4/node_registry/Android.mk
libopencoreplayer.so中包含了以下内容:
libopencoreplayer.so中的内容较多,其中主要为各个文件解析器和解码器,PVPlayer的核心功能在engines/player/Android.mk当中,而android/Android.mk的内容比较特殊,它是在PVPlayer之上构建的一个为Android使用的播放器。
libopencoreauthor.so是用于媒体流记录的功能库,它的编译控制的文件的路径为pvauthor/Android.mk,它包含了以下的内容:
include $(BUILD_SHARED_LIBRARY)
include $(PV_TOP)//engines/author/Android.mk
include $(PV_TOP)//codecs_v2/video/m4v_h263/enc/Android.mk
include $(PV_TOP)//codecs_v2/audio/gsm_amr/amr_nb/enc/Android.mk
include $(PV_TOP)//codecs_v2/video/avc_h264/enc/Android.mk
include $(PV_TOP)//fileformats/mp4/composer/Android.mk
include $(PV_TOP)//nodes/pvamrencnode/Android.mk
include $(PV_TOP)//nodes/pvmp4ffcomposernode/Android.mk
include $(PV_TOP)//nodes/pvvideoencnode/Android.mk
include $(PV_TOP)//nodes/pvavcencnode/Android.mk
include $(PV_TOP)//nodes/pvmediainputnode/Android.mk
include $(PV_TOP)//android/author/Android.mk
libopencoreauthor.so中包含了以下内容:
libopencoreauthor.so中主要为各个文件编码器和文件组成器,PVAuthor的核心功能在engines/author/Android.mk当中,而android/author/Android.mk是在PVAuthor之上构建的一个为Android使用的媒体记录器。
另外的几个库的Android.mk文件的路径如下所示:
网络支持库libopencorenet_support.so:
tools_v2/build/modules/linux_net_support/core/Android.mk
MP4功能实现库libopencoremp4.so和注册库libopencoremp4reg.so:
tools_v2/build/modules/linux_mp4/core/Android.mk
tools_v2/build/modules/linux_mp4/node_registry/Android.mk
RTSP功能实现库libopencorertsp.so和注册库libopencorertspreg.so:
tools_v2/build/modules/linux_rtsp/core/Android.mk
tools_v2/build/modules/linux_rtsp/node_registry/Android.mk
下载功能实现库libopencoredownload.so和注册库libopencoredownloadreg.so:
tools_v2/build/modules/linux_download/core/Android.mk
tools_v2/build/modules/linux_download/node_registry/Android.mk
第三部分 OpenCore OSCL简介
OSCL,全称为Operating System Compatibility Library (操作系统兼容库),它包含了一些在不同操作系统中移植层的功能,其代码结构如下所示:
oscl/oscl
|– config :配置的宏
|– makefile
|– makefile.pv
|– osclbase :包含基本类型、宏以及一些STL容器类似的功能
|– osclerror :错误处理的功能
|– osclio :文件IO和Socket等功能
|– oscllib :动态库接口等功能
|– osclmemory :内存管理、自动指针等功能
|– osclproc :线程、多任务通讯等功能
|– osclregcli :注册客户端的功能
|– osclregserv :注册服务器的功能
`– osclutil :字符串等基本功能
在oscl的目录中,一般每一个目录表示一个模块。OSCL对应的功能是非常细致的,几乎对C语言中每一个细节的功能都进行封装,并使用了C++的接口提供给上层使用。事实上,OperCore中的PVMF、Engine部分都在使用OSCL,而整个OperCore的调用者也需要使用OSCL。
在OSCL的实现中,很多典型的C语言函数被进行了简单的封装,例如:osclutil中与数学相关的功能在oscl_math.inl中被定义成为了内嵌(inline)的函数:
OSCL_COND_EXPORT_REF OSCL_INLINE double oscl_log(double value)
{
return (double) log(value);
}
OSCL_COND_EXPORT_REF OSCL_INLINE double oscl_log10(double value)
{
return (double) log10(value);
}
OSCL_COND_EXPORT_REF OSCL_INLINE double oscl_sqrt(double value)
{
return (double) sqrt(value);
}
oscl_math.inl文件又被oscl_math.h所包含,因此其结果是oscl_log()等功能的使用等价于原始的log()等函数。
很多C语言标准库的句柄都被定义成为了C++类的形式,实现由一些繁琐,但是复杂性都不是很高。以oscllib为例,其代码结构如下所示:
oscl/oscl/oscllib/
|– Android.mk
|– build
|? ?`– make
|? ?? ? `– makefile
`– src
|– oscl_library_common.h
|– oscl_library_list.cpp
|– oscl_library_list.h
|– oscl_shared_lib_interface.h
|– oscl_shared_library.cpp
`– oscl_shared_library.h
oscl_shared_library.h是提供给上层使用的动态库的接口功能,它定义的接口如下所示:
class OsclSharedLibrary
{
public:
OSCL_IMPORT_REF OsclSharedLibrary();
OSCL_IMPORT_REF OsclSharedLibrary(const OSCL_String& aPath);
OSCL_IMPORT_REF ~OsclSharedLibrary();
OSCL_IMPORT_REF OsclLibStatus LoadLib(const OSCL_String& aPath);
OSCL_IMPORT_REF OsclLibStatus LoadLib();
OSCL_IMPORT_REF void SetLibPath(const OSCL_String& aPath);
OSCL_IMPORT_REF OsclLibStatus QueryInterface(const OsclUuid& aInterfaceId, OsclAny*& aInterfacePtr);
OSCL_IMPORT_REF OsclLibStatus Close();
OSCL_IMPORT_REF void AddRef();
OSCL_IMPORT_REF void RemoveRef();
}
这些接口显然都是与库的加载有关系的,而在oscl_shared_library.cpp 中其具体的功能是使用dlopen()等函数来实现的。
在多媒体方面,文件格式的处理和编解码(Codec)是很基础的两个方面的内容。多媒体应用的两个方面是媒体的播放(PlayBack)和媒体的记录(Recording)。
在媒体的播放过程中,通常情况是从对媒体文件的播放,必要的两个步骤为文件的解析和媒体流的解码。例如对于一个mp4的文件,其中可能包括AMR和AAC的音频流,H263、MPEG4以及AVC(H264)的视频流,这些流被封装在3GP的包当中,媒体播放器要做的就是从文件中将这些流解析出来,然后对媒体流进行解码,解码后的数据才可以播放。
在媒体的记录过程中,通过涉及到视频、音频、图像的捕获功能。对于将视频加音频录制成文件功能,其过程与播放刚好相反,首先从硬件设备得到视频和音频的媒体流,然后对其进行编码,编码号的流还需要被分层次写入到文件之中,最终得到组成好的文件。
OpenCore有关文件格式处理和编解码部分两部分的内容,分别在目录fileformats和codecs_v2当中。这两部分都属于基础性的功能,不涉及具体的逻辑,因此它们被别的模块调用来使用,例如:构建各种Node。
由于同时涉及播放文件和记录文件两种功能,因此OpenCore中的文件格式处理有两种类型,一种是parser(解析器),另一种是composer(组成器)。fileformats的目录结构如下所示:
fileformats
|– avi
|? ?`– parser
|– common
|? ?`– parser
|– id3parcom
|? ?|– Android.mk
|? ?|– build
|? ?|– include
|? ?`– src
|– mp3
|? ?`– parser
|– mp4
|? ?|– composer
|? ?`– parser
|– rawaac
|? ?`– parser
|– rawgsmamr
|? ?`– parser
`– wav
`– parser
目录包含各个子目录中,它们对应的是不同的文件格式,例如mp3、mp4和wav等。
编解码部分主要针对Audio和Video,codecs_v2的目录结构如下所示:
codecs_v2
|– audio
|? ?|– aac
|? ?|– gsm_amr
|? ?|– mp3
|? ?`– sbc
|– omx
|? ?|– factories
|? ?|– omx_aac
|? ?|– omx_amr
|? ?|– omx_common
|? ?|– omx_h264
|? ?|– omx_m4v
|? ?|– omx_mp3
|? ?|– omx_proxy
|? ?`– omx_queue
|– utilities
|? ?|– colorconvert
|? ?|– m4v_config_parser
|? ?`– pv_video_config_parser
`– video
|– avc_h264
`– m4v_h263
在audio 和video目录中,对应了针对各种流的子目录,其中可能包含dec和enc两个目录,分别对应解码和编码。video目录展开后的内容如下所示:
`– video
|– avc_h264
|? ?|– common
|? ?|– dec
|? ?|– enc
|? ?`– patent_disclaimer.txt
`– m4v_h263
|– dec
|– enc
`– patent_disclaimer.txt
codecs_v2目录的子目录omx实现了一个khronos
OpenMAX的功能。OpenMAX是一个多媒体应用程序的框架标准,由NVIDIA公司和Khronos在2006年推出。OpenMAX IL 1.0(集成层)技术规格定义了媒体组件接口,以便在嵌入式器件的流媒体框架中快速集成加速式编解码器。
OpenMAX的设计实现可以让具有硬件编辑码功能的平台提供统一的接口和框架,在OpenMAX中可以直接使用硬件加速的进行编解码乃至输出的功能,对外保持统一的接口。但是在此处的OpenMAX则是一个纯软件的实现。
回帖by wsshy:
剖析opencore对于上层应用开发者确实用处不大,但对于如果想扩展android媒体播放器,使其支持FLV,REAL等多种格式就非常有用了。(目前Android的媒体播放器框架还只支持MP4,3Gp等视频格式)
接下来,我们如何基于OpenCore去实现扩展,支持FLV,REAL等多种媒体播放格式呢?
从playerdriver的源码来看,对于音频,视频文件的处理主要涉及到三个对象PVPlayerDataSink,PVMFNodeInterface,AndroidAudioMIO(音频),PvmiMIOControl(视频)。
至于Sink,Node,Control这三者之间的调用,就交由Player引擎来具体处理了
其中PVPlayerDataSink已经默认采用PVPlayerDataSinkPVMFNode这个实现。
AndroidAudioMIO默认使用的是AndroidAudioOutput或者AndroidAudioStream。
PvmiMIOControl默认使用的是AndroidSurfaceOutput。
框架留给我们扩展的地方就只有PVMFNodeInterface了。从node目录下的代码来看,确实也证明了我的猜测。那么,框架是如何知道哪个文件对应哪个PVMFNodeInterface呢?这就得看playengine的代码了,playrengine里涉及到重要的接口,PVPlayerNodeRegistry和PVPlayerRecognizerRegistry。当要播放一个具体的文件时,通过调用这两个接口,engine从而可以找到具体的Node去进行处理。这两个接口的具体实现在pv_player_node_registry.cpp文件中.从构造函数中我们可以清楚的看到各个Node的注册过程,这里各个Node的生成和销毁均采用指针函数。依葫芦画瓢,我们也只要实现类似的Factory即可。
具体如何找到对应的Node参看提供的 QueryRegistry方法和CreateNode方法即可。