Android多媒体框架

时间：2009-05-31

来源：gpephone

在手机上看

手机扫描阅读

Android的核心代码在3月底有一了一次比较重大的改动，尤其是多媒体方面的改动比较大，主要的目的是为了更好的实现Camcorder，以及进一步实现Video Telephony。这些改动也是软、硬件协调、结构和性能折中的一个结果。在此做出一些说明，希望中国的关心Android技术的网友进一步了解 Android发展的历程。

1 ISurface接口的改动

　　ISurface是一个给下层的C++/C代码访问Surface的接口，在JAVA层看不到这一层的逻辑，在以前ISurface接口是比较简单的。

    class ISurface : public IInterface
    {
    public:
        DECLARE_META_INTERFACE(Surface);
        virtual status_t registerBuffers(int w, int h, int hstride, int vstride,
                PixelFormat format, const sp<IMemoryHeap>& heap) = 0;
        virtual void postBuffer(ssize_t offset) = 0; // one-way
        virtual void unregisterBuffers() = 0;
        virtual sp<OverlayRef> createOverlay(
                uint32_t w, uint32_t h, int32_t format) = 0;
    };

　　其中createOverlay()其实表示的使用Overlay时候的接口，一般使用硬件的多个FrameBuffer来实现。这个接口类似一个“旁路”，直接绕过了SurfaceFlinger访问下层的显示硬件，和其他的接口没有什么关系。
主要的改动是registerBuffers()的改动，增加了一个ISurface ::BufferHeap类。

    class BufferHeap {
            enum {
                /* rotate source image 90 degrees */
                ROT_90    = HAL_TRANSFORM_ROT_90,
            };
            BufferHeap(uint32_t w, uint32_t h,
                    int32_t hor_stride, int32_t ver_stride,
                    PixelFormat format, const sp<IMemoryHeap>& heap);
            BufferHeap(uint32_t w, uint32_t h,
                    int32_t hor_stride, int32_t ver_stride,
                PixelFormat format, uint32_t transform, uint32_t flags,
    const sp<IMemoryHeap>& heap);
    /* ......  */
    };

　　registerBuffers()的改动在于使用了新的BufferHeap接口：

　　事实上，BufferHeap()的第一个构造函数与以前没有改动的接口从功能上是相同的。BufferHeap()的第二个构造函数增加了transform和flags两个参数，可以提供更灵活的操作方式，比如使用ROT_90来设置旋转。

　　从操作上，本改动在功能改动不大的情况下却着实涉及了不少的内容，从PVPlayer的显示输出的Surface MIO，SurfaceFlinger的一些实现，Camera服务中的实现。由于ISurface主要用于Playback的输出和Camera / Video Telephony的preview，走的是下层的数据流，因此这个改动不会影响JAVA上层的内容。

　　本次改动的来龙去脉是，以前的ISurface是不支持Overlay的接口，自从年前Overlay接口的确定后，为实现硬件的输出提供了方法。但是使用Overlay则不能使用SurfaceFlinger的2D处理功能，这次接口则增强了ISurface非Overlay接口的功能。比如让其具有了旋转的功能，这样在 PVPlayer等输出显示的时候，就有一个方式可以控制显示的方向。

virtual status_t registerBuffers(const BufferHeap& buffers) = 0;

1．旧的情况

　　由于以前Android的Camera的接口只考虑了Camera本身的情况，没有考虑 Camcorder和Video Telephony的情况，这样接口在很大的程度上就有了局限。以前最上层的Camera接口是frameworks/base/include/ui /中的Camera.h。
根据从前的接口，Camera在使用Overlay和不使用Overlay的情况分别如下所示：

　　Camcorder在使用Overlay和不使用Overlay的情况分别如下所示：

　　从数据流的角度使用Overlay，那么显示的输出将从Camera Hardware Interface的实现直接输出到显示设备上；如果不使用Overlay，则显示的输出通过PreviewCallback输出到Camera Service中有Camera实现输出到ISurface上。
而PreviewCallback是唯一向上层送Video数据的方法，在使用 Overlay的Camera中，由于不需要上层显示，也不需要获取Video数据，因此PreviewCallback是没有用到。在 Camcorder中，Video数据送向Encoder是通过PreviewCallback完成的。尤其在不使用Overlay的Camcorder 中，PreviewCallback其实扮演的双用途。

　　本问题在去年的年底就已经开始讨论，由于Video数据和Preview数据共用一个数据通道，主要的问题是无法在禁止Preview的情况下，向Encoder送出Video数据，这样就不适合了Video Telephony的实现。仅仅对于Camcorder的实现也有问题，无法让Preview和Recording的Video数据使用不同的大小。另外也有一些优化方面无法处理的问题。

2．新的情况

　　在新的接口中，上层的Camera接口和下层的Camera Hardware Interface都实现了Preview和Recording数据通道的分离。
这样没有Overlay情况下的Camcorder的实现如下所示：

　　在上面的情况下，可以看到使用了PreviewCallback和RecorderCallback两个回调函数送上，事实上，对于Camera Service的改动并不大，基本上只是更换了一个函数的名字。对于Camera Hardware Interface的实现，其实变化也不大，数据区可以使用一个，只是通过不同的回调函数送出。使用Overlay的Camcorder如下所示：

　　Camera接口实际上更改了两个地方：
frameworks/base/include/ui/Camera.h
frameworks/base/include/ui/CameraHardwareInterface.h

　　对于前者是上层的Camera接口，对于后者是下层硬件的Camera接口。二者共同的特点是将Preview和Recorder的数据通道进行了分离。

　　从实现上，对于硬件层来说，传输数据的名称只是换了名字而已，由于一般的Camera接口的硬件驱动程序（比如v4l2）不会对Preview和Video数据进行区分，因此实现上的区别也不大。

　　对于上层的Camera接口，在一般情况下。对于Camera的实现，无论是否使用Overlay，这两个Callback都没有使用的；对于 Camcorder的实现，无论是否使用Overlay，RecordingCallback都是向上（Encoder）送数据的。请注意，其实无论哪一种情况，此时的PreviewCallback都是没有用处的，但是接口依然保留。

　　对于Video Telephony，计划的实现方式如下所示：Camera Hardware Interface传输的数据还是一样的，CameraService中不做出Preview，上层数据通过RecordingCallback传输数据到Encorder。

　　本次改动经过了较长时期的，最后的结果还是比较理想的，基本上照顾到了Camera，Camcorder，Video Telephony的实现情况。

　　本次改动为Camera Hardware Interface的实现增加了难度，可能具体Camera Hardware Interface只是实现上述功能一个子集。