|
|
|
@ -8380,12 +8380,16 @@ typedef enum acamera_metadata_enum_acamera_sensor_info_color_filter_arrangement
|
|
|
|
|
// ACAMERA_SENSOR_INFO_TIMESTAMP_SOURCE
|
|
|
|
|
typedef enum acamera_metadata_enum_acamera_sensor_info_timestamp_source {
|
|
|
|
|
/**
|
|
|
|
|
* <p>Timestamps from ACAMERA_SENSOR_TIMESTAMP are in nanoseconds and monotonic,
|
|
|
|
|
* but can not be compared to timestamps from other subsystems
|
|
|
|
|
* (e.g. accelerometer, gyro etc.), or other instances of the same or different
|
|
|
|
|
* camera devices in the same system. Timestamps between streams and results for
|
|
|
|
|
* a single camera instance are comparable, and the timestamps for all buffers
|
|
|
|
|
* and the result metadata generated by a single capture are identical.</p>
|
|
|
|
|
* <p>Timestamps from ACAMERA_SENSOR_TIMESTAMP are in nanoseconds and monotonic, but can
|
|
|
|
|
* not be compared to timestamps from other subsystems (e.g. accelerometer, gyro etc.),
|
|
|
|
|
* or other instances of the same or different camera devices in the same system with
|
|
|
|
|
* accuracy. However, the timestamps are roughly in the same timebase as
|
|
|
|
|
* <a href="https://developer.android.com/reference/android/os/SystemClock.html#uptimeMillis">SystemClock#uptimeMillis</a>. The accuracy is sufficient for tasks
|
|
|
|
|
* like A/V synchronization for video recording, at least, and the timestamps can be
|
|
|
|
|
* directly used together with timestamps from the audio subsystem for that task.</p>
|
|
|
|
|
* <p>Timestamps between streams and results for a single camera instance are comparable,
|
|
|
|
|
* and the timestamps for all buffers and the result metadata generated by a single
|
|
|
|
|
* capture are identical.</p>
|
|
|
|
|
*
|
|
|
|
|
* @see ACAMERA_SENSOR_TIMESTAMP
|
|
|
|
|
*/
|
|
|
|
@ -8395,6 +8399,14 @@ typedef enum acamera_metadata_enum_acamera_sensor_info_timestamp_source {
|
|
|
|
|
* <p>Timestamps from ACAMERA_SENSOR_TIMESTAMP are in the same timebase as
|
|
|
|
|
* <a href="https://developer.android.com/reference/android/os/SystemClock.html#elapsedRealtimeNanos">SystemClock#elapsedRealtimeNanos</a>,
|
|
|
|
|
* and they can be compared to other timestamps using that base.</p>
|
|
|
|
|
* <p>When buffers from a REALTIME device are passed directly to a video encoder from the
|
|
|
|
|
* camera, automatic compensation is done to account for differing timebases of the
|
|
|
|
|
* audio and camera subsystems. If the application is receiving buffers and then later
|
|
|
|
|
* sending them to a video encoder or other application where they are compared with
|
|
|
|
|
* audio subsystem timestamps or similar, this compensation is not present. In those
|
|
|
|
|
* cases, applications need to adjust the timestamps themselves. Since <a href="https://developer.android.com/reference/android/os/SystemClock.html#elapsedRealtimeNanos">SystemClock#elapsedRealtimeNanos</a> and <a href="https://developer.android.com/reference/android/os/SystemClock.html#uptimeMillis">SystemClock#uptimeMillis</a> only diverge while the device is asleep, an
|
|
|
|
|
* offset between the two sources can be measured once per active session and applied
|
|
|
|
|
* to timestamps for sufficient accuracy for A/V sync.</p>
|
|
|
|
|
*
|
|
|
|
|
* @see ACAMERA_SENSOR_TIMESTAMP
|
|
|
|
|
*/
|
|
|
|
|