中财网放马曲:Android多媒体框架3月变化|IT168 技术开发
来源：百度文库 编辑：中财网 时间：2024/04/28 15:05:17
- 第1页：1 ISurface接口的改动
- 第2页：Preview 和Recording接口的分离
{
public:
DECLARE_META_INTERFACE(Surface);
virtual status_t registerBuffers(int w, int h, int hstride, int vstride,
PixelFormat format, const sp
virtual void postBuffer(ssize_t offset) = 0; // one-way
virtual void unregisterBuffers() = 0;
virtual sp
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
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
/* ...... */
}; 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只是实现上述功能一个子集。