mt6735 CTS Camera性能导致测试fail的解决方法
时间：10-02
整理：3721RD
点击：
[DESCRIPTION]
CAMERA是移动设备非常重要的feature, Google对于Camera的CTS测试中有一些比较严格的性能测试，以保证camera程序的用户使用友好度。
Camera CTS测试中性能相关的有很多很多，基本上所有基本功能都有包含性能超时的验证，一般来说是指必须在指定时间返回的测试项。
testVideoSnapshot, testBurstVideoSnapshot,testMandatoryOutputCombinations等等.
如果camera driver以及相应的配置或者测试环境，使得sensor fps较低，就会出现一堆性能测试的fail.
下面就会对于经常出现性能测试fail项的分析和解决方法进行罗列。
[SOLUTION]
1. 请一定使用 userdebug/user版本来验证包含性能相关的测试项：
如果使用的是 eng版本，性能将会变得比较差，一堆性能相关的测试都会失败。
对于camera相关的测试，弊司内部RD测试建议是使用 userdebug版本.
userdebug版本方便抓取一些关键的log,避免只知道结果不知道具体哪里fail的尴尬。
如果贵司的userdebug版本对于user版本有较大的不同，增加了太多的调试信息导致性能变差，请考虑用user版本。
2.请保证前摄或者后摄没有被遮挡，且摄像头均在明亮环境：
后摄：不要将平板直接 放在桌子上进行测试，后摄被遮挡，一般后摄的fps因为外部光源较弱就会被降低，最好 放在支架上，后摄可以对着明亮的电
脑屏幕或者灯光；
前摄： 不要在平板上 前摄盖着东西，或者因为全测时间很长，在夜晚关闭灯光放在 黑暗环境下去测试，这样前摄的fps也很可能被降低,摄最好也 对着灯光。
明亮环境： 可以打开camera，在main log中搜索aaa_state_camera_preview: lv, 此值一般要在60以上
3. 保证camera sensor fps:
最好preview,capture都可以达到 30fps, 建议preview的帧率至少在24fps以上，capture的帧率在15fps以上;
log查看fps:
如果不确定camera sensor fps是多少，可以实际通过log来获得：
打开camera进入预览状态, 在log中搜索handleReturnBuffer,此为display端得到的fps信息，一般和sensor真实的fps比较接近，形如：
D mtkCam/DisplayCLIent: [handleReturnBuffers] + (99) 34ms < Duration(99), Show frame:0 1 [ion:325 0xe65c4000/3110400 89925290000]
其中Duration(99)就是代表此帧是 99ms返回, 这是比较慢的了。
一般，比较理想的环境下，此值 一般为33,除了在因为scenario切换导致的显示时间较大。
实践中，可以发现，camera sensor对着不同亮度的环境，sensor fps很可能跟着变动，一般越是明亮的环境，sensor fps会越大。
可以根据这种操作，来放置测试平台的位置，使得在比较好的亮度环境。
如果发现，camera 已经预览了，log中一直 搜索不到上面的log信息，那有可能是版本为user版本，相关log都被拿掉导致的，就请用 userdebug版本来测试。如果出现此块log怎么都没有显示出来，那请到：
vendor/mediatek/proprietary/hardware/mtkcam/legacy/v1/client/DisplayClient/DisplayClient.BufOps.cpp
handleReturnBuffers函数
MY_LOGD_IF((1<=miLogLevel), "+ %s(%lld) %s(%lld), Show frame:%d %d [ion:%d %p/%d %lld]", ............)；
改成：
MY_LOGD_IF(1, "+ %s(%lld) %s(%lld), Show frame:%d %d [ion:%d %p/%d %lld]", ............)；
Driver部分：
1 理论fps值：此方面需要和sensor FAE或者datasheet确定 设置寄存器的代码，确定sensor输出的理论fps值。
2提高driver性能：
1）减少延时： camera sensor driver 减少 上电延时和driver init/preview/capture/setting/feature control等的延时：
尽可能在符合camera sensor spec的基础上减少延时；
2)camera sensor driver I2C speed提高：
默认的I2C speed应该是100K, 如果camera sensor可支持，可以尝试提高到400K来测试，这样camera driver中读写I2C的速度会提高到之前的4倍；
3)camera driver在不影响画面显示的情况下尽可能 减少delay frame:
如下的数值尽可能减少：
.cap_delay_frame = 3,
.pre_delay_frame = 3,
.video_delay_frame = 3,
不要小看这几个delay的数值，因为实际测试项的执行情况可能调用很多次preview,capture, 有可能少了1就会pass.
实际中，可以先都改为0来测试cts是否可以pass, 如果可以pass, 再查看camera preview/capture/video开始显示画面时是否有黑屏/绿屏/杂线的问
题，如果有，可以酌情增加delay， 同时确保cts也可以pass.
3 如果sensor fps实在太低，cts测试可能 无论怎么优化都不会pass.
4 怎么改都没pass?
实际测试过程中，经常可能遇到，明明main camera已经修改pass了，最后的CTS测试依然是fail，这种情况下，
1 请一定考虑CTS测试一般会测试所有的camera，fail的很可能是另外一颗sensor.
具体方法如下：
1 通过log中TestRunner确定测试开始和结束的时间点；
2 再在上面的log中间搜索openDeviceLocked确定是open第几个camera出现fail的。
一般，如果看到[ openDeviceLocked] + OpenId: 0， 后面 [openDeviceLocked] + OpenId:1 之后fail，那一般就是sub camera fail了。
如果仅仅只有 [openDeviceLocked] + OpenId:0, 那一般说明是main camera就fail了。
当然，不排除有的测试项，根本不会调用open camera，所以不会看到任何openDeviceLocked的log, 也可以根据错误的提示来判断是哪颗sensor
fail的：
例如：
java.lang.Exception: Test failed for camera 1: Test failed for camera 1: Key android.control.aeantibandingMode value 3 isn't one
of the expected values[1,2]
camera 1一般表示 sub camera;
如果是 camera 0, 就一般表示是 main camera.
2 考虑上面提到的光线条件影响。
一般，按照如上的步骤去做，camera cts性能相关测试都会pass. 如果还有fail, 再发CR.
CAMERA是移动设备非常重要的feature, Google对于Camera的CTS测试中有一些比较严格的性能测试，以保证camera程序的用户使用友好度。
Camera CTS测试中性能相关的有很多很多，基本上所有基本功能都有包含性能超时的验证，一般来说是指必须在指定时间返回的测试项。
testVideoSnapshot, testBurstVideoSnapshot,testMandatoryOutputCombinations等等.
如果camera driver以及相应的配置或者测试环境，使得sensor fps较低，就会出现一堆性能测试的fail.
下面就会对于经常出现性能测试fail项的分析和解决方法进行罗列。
[SOLUTION]
1. 请一定使用 userdebug/user版本来验证包含性能相关的测试项：
如果使用的是 eng版本，性能将会变得比较差，一堆性能相关的测试都会失败。
对于camera相关的测试，弊司内部RD测试建议是使用 userdebug版本.
userdebug版本方便抓取一些关键的log,避免只知道结果不知道具体哪里fail的尴尬。
如果贵司的userdebug版本对于user版本有较大的不同，增加了太多的调试信息导致性能变差，请考虑用user版本。
2.请保证前摄或者后摄没有被遮挡，且摄像头均在明亮环境：
后摄：不要将平板直接 放在桌子上进行测试，后摄被遮挡，一般后摄的fps因为外部光源较弱就会被降低，最好 放在支架上，后摄可以对着明亮的电
脑屏幕或者灯光；
前摄： 不要在平板上 前摄盖着东西，或者因为全测时间很长，在夜晚关闭灯光放在 黑暗环境下去测试，这样前摄的fps也很可能被降低,摄最好也 对着灯光。
明亮环境： 可以打开camera，在main log中搜索aaa_state_camera_preview: lv, 此值一般要在60以上
3. 保证camera sensor fps:
最好preview,capture都可以达到 30fps, 建议preview的帧率至少在24fps以上，capture的帧率在15fps以上;
log查看fps:
如果不确定camera sensor fps是多少，可以实际通过log来获得：
打开camera进入预览状态, 在log中搜索handleReturnBuffer,此为display端得到的fps信息，一般和sensor真实的fps比较接近，形如：
D mtkCam/DisplayCLIent: [handleReturnBuffers] + (99) 34ms < Duration(99), Show frame:0 1 [ion:325 0xe65c4000/3110400 89925290000]
其中Duration(99)就是代表此帧是 99ms返回, 这是比较慢的了。
一般，比较理想的环境下，此值 一般为33,除了在因为scenario切换导致的显示时间较大。
实践中，可以发现，camera sensor对着不同亮度的环境，sensor fps很可能跟着变动，一般越是明亮的环境，sensor fps会越大。
可以根据这种操作，来放置测试平台的位置，使得在比较好的亮度环境。
如果发现，camera 已经预览了，log中一直 搜索不到上面的log信息，那有可能是版本为user版本，相关log都被拿掉导致的，就请用 userdebug版本来测试。如果出现此块log怎么都没有显示出来，那请到：
vendor/mediatek/proprietary/hardware/mtkcam/legacy/v1/client/DisplayClient/DisplayClient.BufOps.cpp
handleReturnBuffers函数
MY_LOGD_IF((1<=miLogLevel), "+ %s(%lld) %s(%lld), Show frame:%d %d [ion:%d %p/%d %lld]", ............)；
改成：
MY_LOGD_IF(1, "+ %s(%lld) %s(%lld), Show frame:%d %d [ion:%d %p/%d %lld]", ............)；
Driver部分：
1 理论fps值：此方面需要和sensor FAE或者datasheet确定 设置寄存器的代码，确定sensor输出的理论fps值。
2提高driver性能：
1）减少延时： camera sensor driver 减少 上电延时和driver init/preview/capture/setting/feature control等的延时：
尽可能在符合camera sensor spec的基础上减少延时；
2)camera sensor driver I2C speed提高：
默认的I2C speed应该是100K, 如果camera sensor可支持，可以尝试提高到400K来测试，这样camera driver中读写I2C的速度会提高到之前的4倍；
3)camera driver在不影响画面显示的情况下尽可能 减少delay frame:
如下的数值尽可能减少：
.cap_delay_frame = 3,
.pre_delay_frame = 3,
.video_delay_frame = 3,
不要小看这几个delay的数值，因为实际测试项的执行情况可能调用很多次preview,capture, 有可能少了1就会pass.
实际中，可以先都改为0来测试cts是否可以pass, 如果可以pass, 再查看camera preview/capture/video开始显示画面时是否有黑屏/绿屏/杂线的问
题，如果有，可以酌情增加delay， 同时确保cts也可以pass.
3 如果sensor fps实在太低，cts测试可能 无论怎么优化都不会pass.
4 怎么改都没pass?
实际测试过程中，经常可能遇到，明明main camera已经修改pass了，最后的CTS测试依然是fail，这种情况下，
1 请一定考虑CTS测试一般会测试所有的camera，fail的很可能是另外一颗sensor.
具体方法如下：
1 通过log中TestRunner确定测试开始和结束的时间点；
2 再在上面的log中间搜索openDeviceLocked确定是open第几个camera出现fail的。
一般，如果看到[ openDeviceLocked] + OpenId: 0， 后面 [openDeviceLocked] + OpenId:1 之后fail，那一般就是sub camera fail了。
如果仅仅只有 [openDeviceLocked] + OpenId:0, 那一般说明是main camera就fail了。
当然，不排除有的测试项，根本不会调用open camera，所以不会看到任何openDeviceLocked的log, 也可以根据错误的提示来判断是哪颗sensor
fail的：
例如：
java.lang.Exception: Test failed for camera 1: Test failed for camera 1: Key android.control.aeantibandingMode value 3 isn't one
of the expected values[1,2]
camera 1一般表示 sub camera;
如果是 camera 0, 就一般表示是 main camera.
2 考虑上面提到的光线条件影响。
一般，按照如上的步骤去做，camera cts性能相关测试都会pass. 如果还有fail, 再发CR.