问题背景
在一个双摄项目中, 需要在HAL(使用 API1/HAL1)层集成Bokeh功能(双摄虚化), 同时需要将相关双摄数据回调到App存储, 用于集成Refocus功能(即可以在相册中重新选择虚化焦点和虚化强度). 因此需要回传的数据有, bokeh效果图, 主摄原图, depth数据, bokeh效果图可以走主摄jpeg回调直接返回到App,剩余的两个数据当初考虑使用jpeg callback或者postview callback分两次传回App, 但在实际实施过程中过, 使用postview 回传数据时, App始终只能接受到一次数据, 使用jpeg回传除了bokeh效果图, 其他数据也接收不到,也就是两个回调接口都只能回调一次数据, 这就导致功能没法完成, 这篇文章主要是讲解决这个问题的思路.
解决思路
在解决问题前, 我们已知的信息是: 回调接口使用肯定没有问题, 因为数据的确可以回调, 只是每个回调接口只能回调一次数据而已. 因此最大可能性是回调的数据在某个位置被丢弃了, 所以要解决问题, 就得一步一步看数据回调流程.
关于数据回调流程, 可以参考一下我之前写的Camera架构流程: Android Camera架构
我们主要关注的文件有 :
frameworks/base/core/java/android/hardware/Camera.java
frameworks/base/core/jni/android_hardware_Camera.cpp
frameworks/av/camera/Camera.cpp
frameworks/av/services/camera/libcameraservice/api1/CameraClient.cpp
frameworks/av/services/camera/libcameraservice/device1/CameraHardwareInterface.h
这几个文件中都有数据回调相关的函数(dataCallback), 具体是那些函数就不一一介绍了, 主要讲下解决的思路,
至此, 我们一般有两种方法来定位此问题:
- 详细阅读每个文件中和数据回调相关的函数, 看看那些地方会丢弃回到数据
- 在每个文件的回调函数中关键位置打印一些Log, 编译刷机, 跑下原始流程, 看Log在哪里出现异常
显然第一种方式更利于理解整体流程, 而第二种方式则能更快定位并解决问题, 但都是不错的解决方案.
问题分析
由于我当时项目比较紧急, 所以用的第二种方式解决问题, 通过打印Log, 最终定位到是在CameraClient.cpp中, 回调数据被丢弃了.
关键函数如下:
注: 代码均为 Android 8.0 高通SDM450平台
void CameraClient::dataCallback(int32_t msgType,
const sp<IMemory>& dataPtr, camera_frame_metadata_t *metadata, void* user) {
LOG2("dataCallback(%d)", msgType);
sp<CameraClient> client = getClientFromCookie(user);
if (client.get() == nullptr) return;
if (!client->lockIfMessageWanted(msgType)) return;
if (dataPtr == 0 && metadata == NULL) {
ALOGE("Null data returned in data callback");
client->handleGenericNotify(CAMERA_MSG_ERROR, UNKNOWN_ERROR, 0);
return;
}
switch (msgType & ~CAMERA_MSG_PREVIEW_METADATA) {
case CAMERA_MSG_PREVIEW_FRAME:
client->handlePreviewData(msgType, dataPtr, metadata);
break;
case CAMERA_MSG_POSTVIEW_FRAME:
client->handlePostview(dataPtr);
break;
case CAMERA_MSG_RAW_IMAGE:
client->handleRawPicture(dataPtr);
break;
case CAMERA_MSG_COMPRESSED_IMAGE:
client->handleCompressedPicture(dataPtr);
break;
default:
client->handleGenericData(msgType, dataPtr, metadata);
可以看到, 此函数中会造成数据不往上传有两部分 lockIfMessageWanted()函数和本身数据是否为空的判断, 由于数据为空会有error log打印出来, 所以能确定是lockIfMessageWanted()造成数据被丢弃.
#define CHECK_MESSAGE_INTERVAL 10 // 10ms
bool CameraClient::lockIfMessageWanted(int32_t msgType) {
int sleepCount = 0;
while (mMsgEnabled & msgType) {
if (mLock.tryLock() == NO_ERROR) {
if (sleepCount > 0) {
LOG1("lockIfMessageWanted(%d): waited for %d ms",
msgType, sleepCount * CHECK_MESSAGE_INTERVAL);
}
// If messages are no longer enabled after acquiring lock, release and drop message
if ((mMsgEnabled & msgType) == 0) {
mLock.unlock();
break;
}
return true;
}
if (sleepCount++ == 0) {
LOG1("lockIfMessageWanted(%d): enter sleep", msgType);
}
usleep(CHECK_MESSAGE_INTERVAL * 1000);
}
ALOGW("lockIfMessageWanted(%d): dropped unwanted message", msgType);
return false;
}
可以直观的看到当mMsgEnabled & msgTyp 为false时, 函数返回false, 导致dataCallback()直接返回, 不往下走了, 而 mMsgEnabled & msgType为false表明此时 msgType 没有被启用, 拍照返回jpeg数据使用的msgType为 CAMERA_MSG_COMPRESSED_IMAGE,因此要分析 CAMERA_MSG_COMPRESSED_IMAGE何时被启用和禁用, 搜索关键字后, 可以看到 CAMERA_MSG_COMPRESSED_IMAGE启用是在takePicture()时, 禁用是在拍照数据返回时handleCompressedPicture()
相关代码如下:
//启用, takePicture()函数中的代码片段
// We only accept picture related message types
// and ignore other types of messages for takePicture().
int picMsgType = msgType
& (CAMERA_MSG_SHUTTER |
CAMERA_MSG_POSTVIEW_FRAME |
CAMERA_MSG_RAW_IMAGE |
CAMERA_MSG_RAW_IMAGE_NOTIFY |
CAMERA_MSG_COMPRESSED_IMAGE);
enableMsgType(picMsgType);
//--------------------------------------------------
//禁用 handleCompressedPicture()中的代码片段
if (!mBurstCnt && !mLongshotEnabled) {
LOG1("handleCompressedPicture mBurstCnt = %d", mBurstCnt);
disableMsgType(CAMERA_MSG_COMPRESSED_IMAGE);
}
到此可以看出问题产生的原因是camera framework 本身设计就是拍一次照, 只接受一次数据返回, postview callback也是如此, 多次回调默认是不允许的
解决方案
从上面分析可以看出, 如果不做任何修改, 是没法使用同一个callback在拍照后回调多次数据的,所以解决方法有两种:
- 将所有数据组装到一起, 一次性回到到app
- 修改framework代码, 去除此部分的限制
方法1缺点是要自己组装数据, 并且记录各个数据的大小, 不然app端无法解析数据
方法2高通已经帮我们实现了, 代码如下:
if (!mBurstCnt && !mLongshotEnabled) {
LOG1("handleCompressedPicture mBurstCnt = %d", mBurstCnt);
disableMsgType(CAMERA_MSG_COMPRESSED_IMAGE);
}
高通修改过后, 如果是连拍或者mBurstCnt > 1, 则不会去disable CAMERA_MSG_COMPRESSED_IMAGE这个msg, 而mBurstCnt的值是通过参数获取的, 代码如下:
mBurstCnt = mHardware->getParameters().getInt("num-snaps-per-shutter");
if(mBurstCnt <= 0)
mBurstCnt = 1;
因此我们如果要回调多个数据, 则只需在拍照前, 设置num-snaps-per-shutter这个Camera参数, 其值为我们回调数据的数量, 此功能也会用到高通的一些AOST Feature上, 比如 高通的UbiFocus模式下, num-snaps-per-shutter的值为 7 , 也就是说这个功能会回调7次jpeg数据到app, 高通只修改了jpeg 回调这部分内容, 像postview 和其他数据回调则没有修改, 还是只能拍一次照, 回调一次数据.
总结
- Google原始设计对拍照数据回调有限制, 一次
takePicture()每个callback只能返回一次数据, 数据返回后, 相应MSG会被Disable, 导致后面再回调的数据不会回调App. - 高通对默认流程做了修改, 可通过设置Camera参数, 控制jpeg callback回调的次数.
