awsomeplayer结构认识

把这个搞明白,算是顿悟的一个真实例子。怎么也搞不懂的架构,突然就想明白了。不过这其实是一个思维的过程。

当然如果你想明白这些东西,至少要非常清楚一个概念:接口。

我只是一个半路出家的开发者,我真正明白什么接口时,我已经写了一年多代码了。书面的解释实在拗口,我记不住。

我的理解就是:接口,在C语言里面,就是函数接口,在C++里面就是纯虚函数,在java里面就是interface。用接口,而不是实现来编程一个最大的好处就是:隔离变化。其实这些东西,都是我在李先静老师《系统程序员成长计划》里面领悟到的。

好吧说完了接口的体会,少说废话,步入正题。

我们要思考一个问题,对于一个播放器,解决的主要问题有哪些?当然是播放音视频。如何播放?播放的过程有哪几步?

想到这一点,剩下的东西,就很简单了。

播放器的四大基本组件:access/demux/decode/render。(这些知识,我已经在之前的文章写过了)

下面来看android awesomeplayer是如何抽象这四大组件的。时刻记住,我们是面向接口编程,一定要找准接口。

1.access

有些问题我们之前说过,获取stream的方式是多样的,本地文件,rtsp,http都有可能。我们要足够抽象才行。其实我不知道如何抽象一个好的接口,这也不是这个文章的要点,我们的要点是:印证自己的想法,理解别人的设计理念。

android抽象了一个叫DataSource的接口类,来隔离获stream方式的变化。

virtual status_t initCheck() const = 0;

virtual ssize_t readAt(off64_t offset, void *data, size_t size) = 0;

这个类,规定了两个接口。我们剩下的任务就是找出谁继承了这个类,就知道android能支持的stream种类了。

class FileSource : public DataSource

struct HTTPBase : public DataSource

struct ChromiumHTTPDataSource : public HTTPBase

struct NuCachedSource2 : public DataSource

这里http方式的流,没有直接继承datasource,而是又加了一层包装,另外这个http协议的实现是直接使用的webkit的库。

最后一种stream,我也没搞明白是什么。。。。。

这三种流,分别实现了上述的两个接口,完全了第一步抽象。

2.demux

同理,不同的container,也是需要隔离变化的,avi,mkv,mp4,需要不同的实现。我们不多说其他的,找出基类,看看谁继承了他。

原来他叫MediaExtractor ,再来看看他抽象了什么接口:

virtual size_t countTracks() = 0;
virtual sp<MediaSource> getTrack(size_t index) = 0;

virtual sp<MetaData> getTrackMetaData(size_t index, uint32_t flags = 0) = 0;

ok,原来是这三个接口需要实现。

再来看看谁实现了他。

class AacAdtsExtractor : public MediaExtractor

class AACExtractor : public MediaExtractor

struct ARTSPController : public MediaExtractor

struct AVIExtractor : public MediaExtractor

class DRMExtractor : public MediaExtractor

class FLACExtractor : public MediaExtractor

struct MatroskaExtractor : public MediaExtractor

class MP3Extractor : public MediaExtractor

struct MPEG2TSExtractor : public MediaExtractor

class MPEG4Extractor : public MediaExtractor

struct OggExtractor : public MediaExtractor

class WAVExtractor : public MediaExtractor

这就是android默认支持的demux文件各类了,如果我们要支持新的文件格式,比如flv,就可以新加个类

比如:class FlvExtractor:pulic MediaExtractor这样的,然后实现上述三个接口,就可以支持flv文件格式了。

3.encodec/decodec

这块代码主要是omx在实现,比较复杂,但还是符合我们上述所说的接口抽象,隔离变化的原则的

主要的抽象类是:

MediaSource

virtual status_t start(MetaData *params = NULL) = 0;
   virtual status_t stop() = 0;
   virtual sp<MetaData> getFormat() = 0;

virtual status_t read(MediaBuffer **buffer, const ReadOptions *options = NULL) = 0;

MediaBufferObserver

  virtual void signalBufferReturned(MediaBuffer *buffer) = 0;

这里使用了观察者模式,我不知道为什么要这么设计才好,理解不了这样的设计,但是隐隐知道是有道理的。

实现这两个类的是:

struct OMXCodec : public MediaSource,public MediaBufferObserver

当然是OMXCodec,这个类,隔离了所有的codec的种类,软解,硬解,h264,mpeg4,mp3。。。。。

这是awesomeplayer中最复杂的类,隔离了最复杂的东西,屏避了最大的变化。

从代码分析,原生代码里面omxcodec只支持软解,但是对实际的soc来说,都加入了硬解支持。

下篇文章会分析,omx的组件如何构成以及如何在omxcodec里面加入硬解支持。

4.render。

对于这一步来说,android似乎是最轻松的,因为不用考虑太多变化的问题。因为对android的render来说,实际上没有任何变化。音频直接给audioflinger,图像直接给surfaceflinger。

这里只需要简单包装一下即可。

因为我只对视频有兴趣,我们就看看视频是如何抽象的。这一步甚至已经简单到不用单独起一个文件的地步了。其实整个stragefright目录,除掉上面写的那些类(每个类基本都是一个文件)和一些基本工具类(比如handler,timeevent,string。。类),就没有太多额外的东西了。整体架构比较简洁,比起vlc/directshow这种重型的多媒体框架/应用来说,相当简单。

这个类,只有一个接口。两种实现

struct AwesomeRenderer

virtual void render(MediaBuffer *buffer) = 0;

struct AwesomeLocalRenderer : public AwesomeRenderer

struct AwesomeNativeWindowRenderer : public AwesomeRenderer

local/native不同codec出来的数据

这里有几行注释,

// Hardware decoders avoid the CPU color conversion by decoding
// directly to ANativeBuffers, so we must use a renderer that
// just pushes those buffers to the ANativeWindow.

可以解释这个问题。

localrenderer,额外做了colorspace转化的工作,当然一般都是yv12/nv12(i420p)到rgb565这种,大众的,呵呵,如果你要支持特殊硬件,就要自己手写了。

好了。主要内容就是这些,理一下框架

datasource-->MediaExtractor-->MediaSource--->AwesomeRenderer

四大步,四种抽象接口。与其他的多媒体框架相比,抽象方法是一样的,只是接口略有区别。over..

上一篇:Dalsa线阵CCD相机使用手册


下一篇:40个GitHub上最受欢迎的iOS开源项目