camera_info Struct Reference

#include <camera_common.h>

Data Fields

int facing
 
int orientation
 
uint32_t device_version
 
const camera_metadata_tstatic_camera_characteristics
 
int resource_cost
 
char ** conflicting_devices
 
size_t conflicting_devices_length
 

Detailed Description

Definition at line 160 of file camera_common.h.

Field Documentation

char** conflicting_devices

An array of camera device IDs represented as NULL-terminated strings indicating other devices that cannot be simultaneously opened while this camera device is in use.

This field is intended to be used to indicate that this camera device is a composite of several other camera devices, or otherwise has hardware dependencies that prohibit simultaneous usage. If there are no dependencies, a NULL may be returned in this field to indicate this.

The camera service will never simultaneously open any of the devices in this list while this camera device is open.

The strings pointed to in this field will not be cleaned up by the camera service, and must remain while this device is plugged in.

Version information (based on camera_module_t.common.module_api_version):

CAMERA_MODULE_API_VERSION_2_3 or lower:

Not valid. Can be assumed to be NULL. Do not read this field.

CAMERA_MODULE_API_VERSION_2_4 or higher:

Always valid.

Definition at line 403 of file camera_common.h.

size_t conflicting_devices_length

The length of the array given in the conflicting_devices field.

Version information (based on camera_module_t.common.module_api_version):

CAMERA_MODULE_API_VERSION_2_3 or lower:

Not valid. Can be assumed to be 0. Do not read this field.

CAMERA_MODULE_API_VERSION_2_4 or higher:

Always valid.

Definition at line 418 of file camera_common.h.

uint32_t device_version

The value of camera_device_t.common.version.

Version information (based on camera_module_t.common.module_api_version):

CAMERA_MODULE_API_VERSION_1_0:

Not valid. Can be assumed to be CAMERA_DEVICE_API_VERSION_1_0. Do not read this field.

CAMERA_MODULE_API_VERSION_2_0 or higher:

Always valid

Definition at line 218 of file camera_common.h.

int facing

The direction that the camera faces to. See system/core/include/system/camera.h for camera facing definitions.

Version information (based on camera_module_t.common.module_api_version):

CAMERA_MODULE_API_VERSION_2_3 or lower:

It should be CAMERA_FACING_BACK or CAMERA_FACING_FRONT.

CAMERA_MODULE_API_VERSION_2_4 or higher:

It should be CAMERA_FACING_BACK, CAMERA_FACING_FRONT or CAMERA_FACING_EXTERNAL.

Definition at line 176 of file camera_common.h.

int orientation

The orientation of the camera image. The value is the angle that the camera image needs to be rotated clockwise so it shows correctly on the display in its natural orientation. It should be 0, 90, 180, or 270.

For example, suppose a device has a naturally tall screen. The back-facing camera sensor is mounted in landscape. You are looking at the screen. If the top side of the camera sensor is aligned with the right edge of the screen in natural orientation, the value should be 90. If the top side of a front-facing camera sensor is aligned with the right of the screen, the value should be 270.

Version information (based on camera_module_t.common.module_api_version):

CAMERA_MODULE_API_VERSION_2_3 or lower:

Valid in all camera_module versions.

CAMERA_MODULE_API_VERSION_2_4 or higher:

Valid if camera facing is CAMERA_FACING_BACK or CAMERA_FACING_FRONT, not valid if camera facing is CAMERA_FACING_EXTERNAL.

Definition at line 201 of file camera_common.h.

int resource_cost

The total resource "cost" of using this camera, represented as an integer value in the range [0, 100] where 100 represents total usage of the shared resource that is the limiting bottleneck of the camera subsystem. This may be a very rough estimate, and is used as a hint to the camera service to determine when to disallow multiple applications from simultaneously opening different cameras advertised by the camera service.

The camera service must be able to simultaneously open and use any combination of camera devices exposed by the HAL where the sum of the resource costs of these cameras is <= 100. For determining cost, each camera device must be assumed to be configured and operating at the maximally resource-consuming framerate and stream size settings available in the configuration settings exposed for that device through the camera metadata.

The camera service may still attempt to simultaneously open combinations of camera devices with a total resource cost > 100. This may succeed or fail. If this succeeds, combinations of configurations that are not supported due to resource constraints from having multiple open devices should fail during the configure calls. If the total resource cost is <= 100, open and configure should never fail for any stream configuration settings or other device capabilities that would normally succeed for a device when it is the only open camera device.

This field will be used to determine whether background applications are allowed to use this camera device while other applications are using other camera devices. Note: multiple applications will never be allowed by the camera service to simultaneously open the same camera device.

Example use cases:

Ex. 1: Camera Device 0 = Back Camera Camera Device 1 = Front Camera

  • Using both camera devices causes a large framerate slowdown due to limited ISP bandwidth.

Configuration:

Camera Device 0 - resource_cost = 51 conflicting_devices = null Camera Device 1 - resource_cost = 51 conflicting_devices = null

Result:

Since the sum of the resource costs is > 100, if a higher-priority application has either device open, no lower-priority applications will be allowed by the camera service to open either device. If a lower-priority application is using a device that a higher-priority subsequently attempts to open, the lower-priority application will be forced to disconnect the the device.

If the highest-priority application chooses, it may still attempt to open both devices (since these devices are not listed as conflicting in the conflicting_devices fields), but usage of these devices may fail in the open or configure calls.

Ex. 2: Camera Device 0 = Left Back Camera Camera Device 1 = Right Back Camera Camera Device 2 = Combined stereo camera using both right and left back camera sensors used by devices 0, and 1 Camera Device 3 = Front Camera

  • Due to do hardware constraints, up to two cameras may be open at once. The combined stereo camera may never be used at the same time as either of the two back camera devices (device 0, 1), and typically requires too much bandwidth to use at the same time as the front camera (device 3).

Configuration:

Camera Device 0 - resource_cost = 50 conflicting_devices = { 2 } Camera Device 1 - resource_cost = 50 conflicting_devices = { 2 } Camera Device 2 - resource_cost = 100 conflicting_devices = { 0, 1 } Camera Device 3 - resource_cost = 50 conflicting_devices = null

Result:

Based on the conflicting_devices fields, the camera service guarantees that the following sets of open devices will never be allowed: { 1, 2 }, { 0, 2 }.

Based on the resource_cost fields, if a high-priority foreground application is using camera device 0, a background application would be allowed to open camera device 1 or 3 (but would be forced to disconnect it again if the foreground application opened another device).

The highest priority application may still attempt to simultaneously open devices 0, 2, and 3, but the HAL may fail in open or configure calls for this combination.

Ex. 3: Camera Device 0 = Back Camera Camera Device 1 = Front Camera Camera Device 2 = Low-power Front Camera that uses the same sensor as device 1, but only exposes image stream resolutions that can be used in low-power mode

  • Using both front cameras (device 1, 2) at the same time is impossible due a shared physical sensor. Using the back and "high-power" front camera (device 1) may be impossible for some stream configurations due to hardware limitations, but the "low-power" front camera option may always be used as it has special dedicated hardware.

    Configuration:

    Camera Device 0 - resource_cost = 100 conflicting_devices = null Camera Device 1 - resource_cost = 100 conflicting_devices = { 2 } Camera Device 2 - resource_cost = 0 conflicting_devices = { 1 } Result:

    Based on the conflicting_devices fields, the camera service guarantees that the following sets of open devices will never be allowed: { 1, 2 }.

    Based on the resource_cost fields, only the highest priority application may attempt to open both device 0 and 1 at the same time. If a higher-priority application is not using device 1 or 2, a low-priority background application may open device 2 (but will be forced to disconnect it if a higher-priority application subsequently opens device 1 or 2).

Version information (based on camera_module_t.common.module_api_version):

CAMERA_MODULE_API_VERSION_2_3 or lower:

Not valid. Can be assumed to be 100. Do not read this field.

CAMERA_MODULE_API_VERSION_2_4 or higher:

Always valid.

Definition at line 375 of file camera_common.h.

const camera_metadata_t* static_camera_characteristics

The camera's fixed characteristics, which include all static camera metadata specified in system/media/camera/docs/docs.html. This should be a sorted metadata buffer, and may not be modified or freed by the caller. The pointer should remain valid for the lifetime of the camera module, and values in it may not change after it is returned by get_camera_info().

Version information (based on camera_module_t.common.module_api_version):

CAMERA_MODULE_API_VERSION_1_0:

Not valid. Extra characteristics are not available. Do not read this field.

CAMERA_MODULE_API_VERSION_2_0 or higher:

Valid if device_version >= CAMERA_DEVICE_API_VERSION_2_0. Do not read otherwise.

Definition at line 240 of file camera_common.h.


The documentation for this struct was generated from the following file: