这篇文章主要讲camerahal接口调用流程和使用方法
如果是写camerhal的厂家，这个应该是必看的，对于想学习camerahal有绝对的指导意义。甚至于是基于camerahal也能开发apk
Camera3.h 注释自我笔记
1.Camerahal 的版本号:
Hal接口camera_module_t.get_camera_info camera_module_t.common.module_api_version
实现接口
CameraHWInfo::CameraHWInfo() :
mMainDevicePathName(DEFAULT_MAIN_DEVICE),
mHasMediaController(false)
{
mBoardName = “”;
mProductName = “<not_set>”;
mManufacturerName = “”;
mCameraDeviceAPIVersion = CAMERA_DEVICE_API_VERSION_3_3;
说明是hal3.3
2调用流程
2.1 framework调用camera_module_t->common.open，返回hardware_device_t
2.2 检查hal的版本号，并实例化对应的handler，比如是3.0版本，那么可以将其强制转换成camera3_device_t
2.3 调用camera3_device_t->ops->initialize()，设置回调函数。
2.4 调用camera3_device_t->ops->configure_streams()，配置一系列输入输出流到hal
2.5 如果小于或等于3.1版本，要分配gralloc buffers，调用camera3_device_t->ops->register_stream_buffers至少配置一个输出，同样的stream只能注册一次
大于3.1版本camera3_device_t->ops->register_stream_buffers()不需要调用。
因为当前的3.3 所以该函数不用调用
2.6对一些用可以使用默认的设置，camera3_device_t->ops->construct_default_request_settings()，可以在第三部之后任何地方调用
2.7 基于一组默认设置，发送一个capture 请求，必须至少包含一个输出stream，这个是之前注册过的（应该是第四步做的），调用camera3_device_t->ops->process_capture_request()。这个请求必须在hal能接受下一个请求之后返回（或者说返回之后，hal就可以接受下一个请求）。
注意当版本大于3.2时，camera3_stream_buffer_t，可以是之前没注册过的
2.8 连续提交请求，并调用construct_default_request_settings以获取其他用例的默认设置缓冲区（就是camera_metadata_t结构）。
在3.1及以下版本可能会调用为没有注册的stream 调用register_stream_buffers函数
2.9 当捕获请求开始时（曝光开始）或者重处理时，hal需要调用camera3_callback_ops_t->notify()报告SHUTTER事件，里面包含帧号和曝光时间戳。对于重处理请求，时间戳是可以在输入画面调用process_capture_request时候传入的camera3_capture_request_t.settings的android.sensor.timestamp查找
小于等于3.1版本，这个调用必须在process_capture_result调用之前，他会使用帧号。
大于3.1，hal必须尽早调用这个notify因为framework将没办法将gralloc buffers传递到应用层，直到有这个开始曝光的时间戳（或者输入图像的开始曝光用于重新处理请求）。
部分metadata结果和gralloc buffer 会在SHUTTER事件前后的任何时候返回到framework层。
2.10 一些pipeline延时之后（应该是数据在硬件上流转时间），hal使用amera3_callback_ops_t->process_capture_result()开始返回完整的捕获数据到framework，返回是按照请求下发顺序来的，根据pipeline的深度，可以同时执行多个请求。
在大于3.1版本，一旦buffer作为camera3_stream_buffer_t的一部分通过process_capture_result返回，并且release_fence被标记（-1表示不允许操作），这个buffer的所有权将被视为转回framework，之后hal将不再保留这个特定buffer，framework将立即为它清理内存
对于单帧，process_capture_result可能被多次调用，每次返回部分新的metadata或者(和)gralloc buffers，framework将积累这些metadata到一个结果
下列特殊情况可以调用process_capture_result
同时N帧和N+1帧，只要规则适用于gralloc buffer（是一个返回对应多个帧？）
2.11 一段时间后，framework会停止下发新的request，等待完成现有的captures（buffer 填充，结果返回），然后再调用configure_streams()，这是为新的输入输出stream复位（配置）camera hardware和pipeline。一些stream可能被之前的配置重用。如果这些streams的buffer已经被hal注册，他们不会再次register，如果至少有一个output stream存在，framework会继续步骤7，否则还是要步骤5注册。
2.12 framewrok可以调用camera3_device_t->common->close()去结束camera回话。当framwwork没有其他调用为active状态时（也就是poll状态也可以），可以随时调用。尽管这个调用可能会阻塞直到所有in-flight captures完成（所有result返回，所有buffer被填充） 。这个colse调用返回后，不允许hal调用camera3_callback_ops_t函数。一旦close开始，frame也不可以调用任何hal的函数。
2.13 如果发生错误或其他异步事件，HAL必须调用camera3_callback_ops_t->notify（）包含适当的错误/事件信息。当设备错误信息返回后，hal要像close被调用一样操作。然而，hal必须在调用notify()之前取消或完成所有未完成的capture.因此一旦notify被调用返回错误信息，framework将不会受到进一步的callbacks。除了close（）之外的方法应在notify()返回错误之后返回-ENODEV或NULL。
3 操作模式
camera 3 HAL设备可以实现两种可能的操作模式之一：有限模式和满模式。新的高端设备有望提供全面支持。有限模式对硬件的要求大致与相机HAL设备v1实现的要求一致，一般是旧的或便宜的设备。Full是limited的严格父集，它们共享相同的基本操作流程，如上面所述。
hal必须用android.info.supportedHardwareLevel静态metadata entry，0表示有限模式，1表示完全模式支持。
所以 rk在camera3_profiles定义的是 <info.supportedHardwareLevel value=“LIMITED”/>
粗略地说，limited模式设备不允许应用程序控制捕获设置（仅3A控制），高分辨率时候高速捕获图像，读取rawdata，或支持YUV输出流高于最大录像分辨率（JPEG只针对大型图像）。感觉rk应该可以做FULL.
Limited细节表现
有限模式设备不需要在捕获请求设置和捕获的实际图像数据之间实现精确同步, 相反，对设置的更改可能会在将来的某个时间生效，并且可能不会对每个设置项的同一输出帧生效, 快速的设置更改可能会导致某些设置从未用于捕获(就是设置下去被冲掉了), 但是，包含高分辨率output buffer（>1080p）的捕获必须使用指定的设置（但有关处理速率，请参见下文）。
Limited模式设备不需要支持大多数setting/result/static metadata信息。具体地说，只有以下设置可能被消耗或者处理(使用到)：
- android.control.aeAntibandingMode (controls and dynamic)
- android.control.aeExposureCompensation (controls and dynamic)
- android.control.aeLock (controls and dynamic)
- android.control.aeMode (controls and dynamic)
- android.control.aeRegions (controls and dynamic)
- android.control.aeTargetFpsRange (controls and dynamic)
- android.control.aePrecaptureTrigger (controls and dynamic)
- android.control.afMode (controls and dynamic)
- android.control.afRegions (controls and dynamic)
- android.control.awbLock (controls and dynamic)
- android.control.awbMode (controls and dynamic)
- android.control.awbRegions (controls and dynamic)
- android.control.captureIntent (controls and dynamic)
- android.control.effectMode (controls and dynamic)
- android.control.mode (controls and dynamic)
- android.control.sceneMode (controls and dynamic)
- android.control.videoStabilizationMode (controls and dynamic)
- android.control.aeAvailableAntibandingModes (static)
- android.control.aeAvailableModes (static)
- android.control.aeAvailableTargetFpsRanges (static)
- android.control.aeCompensationRange (static)
- android.control.aeCompensationStep (static)
- android.control.afAvailableModes (static)
- android.control.availableEffects (static)
- android.control.availableSceneModes (static)
- android.control.availableVideoStabilizationModes (static)
- android.control.awbAvailableModes (static)
- android.control.maxRegions (static)
- android.control.sceneModeOverrides (static)
- android.control.aeState (dynamic)
- android.control.afState (dynamic)
- android.control.awbState (dynamic)
- android.flash.mode (controls and dynamic)
- android.flash.info.available (static)
- android.info.supportedHardwareLevel (static)
- android.jpeg.gpsCoordinates (controls and dynamic)
- android.jpeg.gpsProcessingMethod (controls and dynamic)
- android.jpeg.gpsTimestamp (controls and dynamic)
- android.jpeg.orientation (controls and dynamic)
- android.jpeg.quality (controls and dynamic)
- android.jpeg.thumbnailQuality (controls and dynamic)
- android.jpeg.thumbnailSize (controls and dynamic)
- android.jpeg.availableThumbnailSizes (static)
- android.jpeg.maxSize (static)
- android.lens.info.minimumFocusDistance (static)
- android.request.id (controls and dynamic)
- android.scaler.cropRegion (controls and dynamic)
- android.scaler.availableStreamConfigurations (static)
- android.scaler.availableMinFrameDurations (static)
- android.scaler.availableStallDurations (static)
- android.scaler.availableMaxDigitalZoom (static)
- android.scaler.maxDigitalZoom (static)
- android.scaler.croppingType (static)
- android.sensor.orientation (static)
- android.sensor.timestamp (dynamic)
- android.statistics.faceDetectMode (controls and dynamic)
- android.statistics.info.availableFaceDetectModes (static)
- android.statistics.faceIds (dynamic)
- android.statistics.faceLandmarks (dynamic)
- android.statistics.faceRectangles (dynamic)
- android.statistics.faceScores (dynamic)
- android.sync.frameNumber (dynamic)
- android.sync.maxLatency (static)
在camera3_profiles.xml中发现部分动态的也会被预置值
request.availableResultKeys 表示返回的resultkey
request.availableRequestKeys 表示下发的RequestKeys
以上两个都没有默认值，里面的应该是支持的key吧？那就没实现这里的全部
在Limited模式包含大于1080p的 output buffers可能会被process_capture_request()阻塞，直到所有buffer被填充。Full模式的设备必须以static metadata定义的速率处理高分辨率request，hal仍然要调用process_capture_result()提供结果，framework必须简单地准备好让process_capture_request（）阻塞，直到该请求的process_capture_result（）完成有限模式设备的高分辨率捕获???
FULL模式设备必须支持以下附加功能：
最大分辨率能达到30帧最好，需要20帧以上
每帧控制 (android.sync.maxLatency == PER_FRAME_CONTROL).rk也有配置
手动控制metadata，查看定义在android.request.availableCapabilities 的MANUAL_SENSOR
Post手动处理metadata 查看定义在android.request.availableCapabilities的
MANUAL_POST_PROCESSING
这两个rk没有
4 3a模式和状态机：
3A算法取决于HAL实现， HAL接口定义了高级状态机描述，以允许HAL设备和框架就3A的当前状态进行通信，并触发3A事件
当设备打开时，所有单独的3A状态必须非活动状态。Stream配置没有重置3A。例如，必须在调用configure（）中锁定焦点。
触发3A操作只需在下一个请求的设置中设置相关的触发器条目，以指示触发器的启动
例如，启动自动对焦扫描的触发器是将一个请求的entry ANDROID_CONTROL_AF_TRIGGER设置成ANDROID_CONTROL_AF_TRIGGER_START
取消自动对焦设置ANDROID_CONTROL_AF_TRIGGER成ANDROID_CONTRL_AF_TRIGGER_CANCEL
否则，这个entry会不存在，或者设置成ANDROID_CONTROL_AF_TRIGGER_IDLE，每个将触发器项设置为非idle值的请求将被视为独立触发事件
3A由ANDROID_CONTROL_模式设置为总控制开关,RK用做request和result 的key
ANDROID_CONTROL_MODE_OFF关闭3a
ANDROID_CONTROL_MODE_AUTO 正常自动模式
ANDROID_CONTROL_USE_SCENE_MODE 为情景模式
在OFF模式下，每个单独的AE/AF/AWB模式有效关闭，并且任何捕获控件都不能被3A例程重写
在自动模式下，自动对焦、自动曝光和自动白平衡都运行各自独立的算法，并具有自己的模式、状态和触发metadata entry，如下一节所列
情景模式ANDROID_CONTROL_SCENE_MODE的值决定3a例程，在SCENE_MODEs而不是FACE_PRIORITY（SCENE_MODE的一种，就是face优先，3a值应该得保存，我理解是这样），hal必须重写ANDROID_CONTROL_AE/AWB/AF_MODE的值，也就是特定的场景写不同的值，有不同效果。比如，SCENE_MODE_NIGHT，使用连续对焦模式，任何用户的选择AE/AWB/AF模式都会被忽略。这个举例是不是有点欠妥
SCENE_MODE_FACE_PRIORITY 3a的参数按照CONTROL_MODE_AUTO来。但是3a程序必须偏向于测量和聚焦在检测到的人脸上。
4.1 自动对焦设置和result entries
主要entries
ANDROID_CONTROL_AF_MODE 选择当前对焦模式，framework发送request设置
ANDROID_CONTROL_AF_STATE 动态metadata描述当前af算法状态，作为结果返回
ANDROID_CONTROL_AF_TRIGGER 相关触发3a开启关闭和idle，发送request设置
4.2 4.3AE和AWB都是差不多，AWB没有TRIGGER。每种mode state和trigger都有很多枚举值。
4.4 通用状态机转换说明
在AF、AE或AWB模式之间切换总是将算法的状态重置为inactive状态。同样在切换CONTORL_MODE或是使用CONTROL_MODE == USE_SCENE_MODE，将会置所有3a算法状态为INACTIVE状态
4.5 4.6 af/ae/awb 状态机的切换 //todo
5 裁剪
ANDROID_SCALER_CROP_REGION可以设置全分辨率裁剪（数字变焦和小视场），这是pre-request（？？？），对于实现平滑的数字边角比较重要。
简单说下这里：(x, y, width, height)矩形范围，x和y为(0,0)表示左上角最大有效像素，因此，width和height不能大于ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY静态，允许的最小值由ANDROID_SCALER_MAX_DIGITAL_ZOOM来决定，它也描述了最大的zoom因子，因此最小裁剪的范围宽高为
- {width, height} =
{ floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[0] /
ANDROID_SCALER_MAX_DIGITAL_ZOOM),
floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[1] /
ANDROID_SCALER_MAX_DIGITAL_ZOOM) }
如果裁剪区域需要满足特定要求（例如，它需要从偶数坐标开始，宽度/高度需要偶数），HAL必须进行必要的舍入，并写出输出结果metadata中使用的最终裁剪区域。类似的，如果HAL实现video固定（分辨率），则它必须调整结果裁剪区域以匹配固定的video区域。一般来说，使用应用程序的相机必须能够根据裁剪区域、图像传感器的尺寸和镜头焦距确定其接收的视野。
假设裁剪是在将原始颜色应用到其他颜色空间之后进行的转换。原始流（RAW16和Raw_OPAQUE）没有这个转换阶段，不可裁剪。因此，HAL必须忽略raw stream。
Crop只针对非raw stream，相比crop区域有很多不同的比例，实际sensor区域能会小于crop区域，具体地说，每个stream都应该维持他的宽高比例。如果stream的长宽比比crop区宽，则stream应垂直crop，如果stream的长宽比比作物区窄，stream水平crop。
Crop必须在full crop区域的中心，每个stream只能是水平或者垂直crop
后面例子不说，crop应该都清楚
6 错误管理
如果发生严重错误，具有返回值的Camera HAL device ops函数都将返回-ENODEV/NULL。这意味着设备无法继续运行，必须由框架关闭。一旦某个方法返回此错误，或者调用notify（）通知ERROR_DEVICE，则只能成功调用close（）方法。所有其他方法都将返回-ENODEV/NULL.
如果操作错误的时序，例如framewrok调用config_streams在initialize，设备必须返回-ENOSYS.
图像捕获中的暂时错误必须通过notify（）报告，如下所示：
整个捕获失败必须由HAL调用notify报告ERROR_REQUEST时间，在这种情况下，不能报告metadata个别错误或outputbuffer。
如果capture的metadata不能处理，但是image buffers已经被填充，hal必须要调用notify 报告ERROR_RESULT信息
如果output image buffer填充不了，但是metadata被处理或者一些其他buffer被填充，hal调用notify报告ERROR_BUFFER
在这些暂时的故障情况中，HAL必须仍然调用process_capture_result，并使用有效的输出和输入（如果提交了输入缓冲区）buffer_handle_t。如果无法生成结果metadata，则应为空. 如果无法填充某些buffer,他们必须用process_capture_result返回错误状态
Release fences必须通过framework设置为acquire fences，或者如果他已经在被hal等待，将被设置成-1。
无效的输入参数导致-EINVAL，在这种情况下，framework必须像从未发出过那样
7. Key Performance Indicator (KPI) 词汇
Pipeline Latency:管道时延
对于给定的capture request，从框架调用process_capture_request到HAL发送捕获结果以及process_capture_result调用返回的所有缓冲区的持续时间。为了使管道延迟的测量独立于帧速率，它是通过帧计数来测量的。
例如，当帧速率为30（fps）时，帧持续时间（相邻帧捕获时间之间的时间间隔）为33（ms），如果框架需要5帧才能得到request结果和返回buffers，则管道延迟为5（帧），而不是5 x 33=165（ms）
管道延迟由android.request.pipelineDepth和
android.request.pipelineMaxDepth，请参阅它们的定义以了解更多详细信息。
8 使用例子
包含了hal支持的典型使用例子
8.1 0秒快拍，使用CAMERA3_STREAM_BIDIRECTIONAL类型的stream
使用这个双向stream将被framework做如下使用：
@1 framework包含一个output buffer的普通stream的request
@2 一旦hal返回一个填充的output buffer，framework将对这个buffer做两者之一
@2.a framework使用填充的buffer，返回now-uesd buffer队列重用(这是什么?可能是得到buffer的正常使用),这和output 类型stream一样。
@2.b framework处理这个填充的buffer，把这个buffer作为输入buffer做一个request，一旦hal处理了这个buffer，然后返回到framework，他会返回now-used buffer到stream 队列重用。
@3 HAL设备将在将来的某个时刻再次被赋予这个buffer作为request的output buffer
对于ZSL用例，在android.scaler.availableInputOutputFormatsMap中有支持的话。双向流的像素格式将是HAL_pixel_format_RAW_OPAQUE或HAL_pixel_format_IMPLEMENTATION，当使用HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED时，gralloc的usage编制将被设置成GRALLOC_USAGE_HW_CAMERA_ZSL。具有BIDIRECTIONAL stream作为输入，通常也具有不同的outputstream以获取重新处理的数据。例如 zsl用例：Stream将被这样配置：
一个HAL_PIXEL_FORMAT_RAW_OPAQUE bidirectional stream作为输入
HAL_PIXEL_FORMAT_BLOB作为输出
8.2 zsl 被作为CAMERA3_STREAM_INPUT处理。
当摄像机设备支持OPAQUE_REPROCESSING，input stream可以被APP/framework实现ZSL。这种stream将被framework做如下使用：
@1 app/framework 配置opaque（基于raw或者yuv）格式输出stream用作生成ZSL的output buffers，stream的pixel格式为HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED。APP/framework配置opaque格式input stream，他发送处理zsl buffer到hal。这个pixel 格式也同样是HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED
@2 APP/framework配置yuv/jpeg output stream,用他来接收处理好的数据，这个stream的pixle format 会是YCbCr_420/HAL_PIXEL_FORMAT_BLOB.
@3 当应用程序发出ZSL捕获时，APP/framework 从output stream收取 zsl buffer，并在重新处理请求中将数据作为input buffer发送回HAL进行重新处理
@4 Hal将output yuv/jpeg数据作为结果发送到framework
Hal可以基于HAL_PIXEL_format_IMPLEMENTATION_DEFINED format和gralloc usage flag gralloc_usage_HW_CAMERA_ZSL去选择实际opaque buffer格式和配置适当的isp pipeline
8.3 YUV 使用CAMERA3_STREAM_INPUT stream重处理
当hal支持yuv数据重处理时，input stream可以用做lucky-shot和图像拼接。这种stream将会被Framework这样使用
@1 APP/framework配置一个YCbCr_420 格式output stream，用他产生一个output buffer
@2 APP/framework配置一个YCbCr_420 格式input stream，用他发送重处理yuv buffer到hal
@3 APP/framework配置一个YUV/JPEG output stream用作接受重处理好的数据，stream 的pixl 格式会是YCbCr_420/HAL_PIXEL_FORMAT_BLOB
@4 APP/framework当一个capture发送，从output stream处理output buffers（也可能简单的直接接收 output buffer），然后发送回这个data作为一个input buffer 重处理request，然后发送到hal重处理
@5 Hal将output yuv/jpeg数据作为结果发送到framework
9 关于control和metadata的说明
这个片段包含各种metadata tags的理解和使用
9.1 HIGH_QUALITY 和 FAST 模式
许多camera有一些类似HIGH_QUALITY,FAST, 和 OFF 操作模式的后处理块，这些处理模块通常还有一个’可用模式’tag，表示在给定社保上哪些操作模式可用，实现这些模式一般策略如下：
@1. 操作模式control硬件模块不能disable，相应的’可用模式’不能off状态
@2. 如果可以关闭那个硬件block他的’可用模式’tag将被设置为OFF
@3. 对于设备上支持的所有后处理块，FAST必须始终包含在“可用模式”标记中。如果后处理块还具有速度较慢且质量较高的操作模式，而该操作模式不满足快速模式的帧速率要求，则HIGH_QUALITY应该包含在“可用模式”标签中以表示此操作模式
10. 重处理 flow 和 controls
本节介绍OPAQUE和YUV 处理folw和controls。OPAQUE处理使用应用不能可视的opaque格式，app只能选择一些output buffer发送到hal做重处理，当YUV重处理给应用机会处理buffer（也就是选转换为yuv），然后再处理。
第8节说明了stream的电影处理配置，这节对buffer flow和controls做更小细节的说明
10.1 OPAQUE（通常用于zsl）重处理flow和controls
OPAQUE重处理例子(例如zsl)，app创建制定的output和input stream，运行buffer flow和controls制定如下：
@1． app通过为得到output opaque buffer和预览发送repeat request启动output stream，buffer 由一组固定的环形buffer保存。这个request基于CAMERA3_TEMPLATE_ZERO_SHUTTER_LAG capture 模版，该模板应具有所有必要的设置，以确保输出帧速率不会相对于sensor（摄像头）输出帧速率减慢。
@2． app基于应用程序buffer的选择逻辑（例如 good ae 和af 统计）选择一个output buffer， 发送capture消息。然后基于capture 返回选定的buffer创建一个新的处理请求，这个选定的output buffer，现在作为input buffer添加到此重新处理请求，此重新处理请求的output buffer应为JPEG或者yuv outputbuffer，或者都有，具体取决于app的选择
@3． App更改重新处理设置以获得最佳图像质量。如果HAL支持OPAQUE_REPROCESSING属性，HAL必须支持且仅支持以下控制：
-android.jpeg.*（如果输出中包含jpeg缓冲区）
-android.noiseReduction.mode（如果支持，则更改为高质量）
*-android.edge.mode（如果支持，则更改为高质量）
HAL必须忽略所有其他controls
@4. HAL处理了input buffer并在capture results中返回utput buffers像平常一样
10.2 YUV重处理flow和controls
Yuv处理buffer flow和OPAQUE 处理相似，有以下不同：
@1. app可能需要对中间YUV图像进行更精细的像素控制（在重新处理之前）。例如，应用程序可以选择android.noiseReduction.mode == MINIMAL，为了保证输出的YUV buffer 减少噪声，可以对其进行先进的降噪处理。对于OPAQUE 的情况，没有关系，只要最后处理的图像有最好的质量
@2. 应用程序可以修改YUV输出缓冲区数据。例如，对于图像融合用例，将多个输出图像合并在一起以提高信噪比比率（SNR），app可以从多个buffer区（多个合成一个）生成input buffer。为了避免对input buffer应用过多的噪声降低和不足的边缘增强，app可以提示HAL应用程序已经完成了多少有效的曝光时间提升，然后，HAL可以调整去噪和边缘增强参数，以获得最佳的后处理图像质量
以下标签可用于此目的：
-android.reproces.effectiveExposureFactor系统
该值是应用于原始输出图像的曝光时间增加因子，例如，如果有N个图像合并，则曝光时间增加因子将高达sqrt（N）。有关更多详细信息，请参阅此标记规范。
10.3 Reprocessing pipeline 特性
后处理管道与正常输出管道相比具有以下不同的特性:
@1.重新处理结果可以在挂起的正常输出结果之前返回。但是，对于所有的后处理结果，必须保持FIFO顺序。例如，HAL正在处理以下请求（A代表输出请求，B代表重新处理请求）：
A1, A2, A3, A4, B1, A5, B2, A6…
B1可以在A1-A4之前返回，但是B2必须B1之后返回
@2.单一输入规则：对于给定的重新处理请求，所有output buffer必须来自input buffer，而不是传感器输出。例如，如果重新处理请求同时包含JPEG和preview buffers，所有output buffer 都必须从重新处理请求所包含的input buffer生成，而不是从sensor生成，hal不能从传感输出 preview buffers，而从input buffer输出jpeg buffer（怎么这么多废话）
@3. Input buffer将直接从camera output（zsl 情况）或间接（图像合成）。对于修改buffer的情况，大小保持不变，如果发送来自未知源的buffer，HAL可以notify CAMERA3_MSG_ERROR_请求
@4. 作为重新处理请求的结果：HAL可以期望重新处理请求是一个输出结果的副本，其中包含允许的少量设置更改。如果是未知源的请求，则hal可以通知如果发出CAMERA3_MSG_ERROR_REQUEST。
@5. Output buffers不能用做跨配置流边界（cross the configure stream boundary）的input，这是因为像ZSL output stream这样的opaque stream在ZSL缓冲区内可能具有不同的实际图像大小，以节省用于较小分辨率JPEG捕获的功率和带宽，如果发生这种情况，HAL可以notify CAMERA3_MSG_ERROR_请求
@6. HAL在FLUSH期间重新处理请求错误报告应遵循flush（）方法指定的相同规则.
扫一扫
5358
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
