技术开发 频道

Android多媒体框架3月变化

  【IT168 技术文档】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只是实现上述功能一个子集。

 

0
相关文章