Android.Hardware.Camera2.Params.StreamConfigurationMap.GetOutputStallDuration Method
Get the stall duration for the format/size combination (in nanoseconds).

Syntax

[Android.Runtime.Register("getOutputStallDuration", "(ILandroid/util/Size;)J", "")]
public long GetOutputStallDuration (int format, Android.Util.Size size)

See Also

Android.Hardware.Camera2.CaptureRequest.SensorFrameDuration
Android.Graphics.ImageFormat
Android.Graphics.PixelFormat

Parameters

format
an image format from Android.Graphics.ImageFormat or Android.Graphics.PixelFormat
size
an output-compatible size

Returns

Documentation for this section has not yet been entered.

Exceptions

TypeReason
Java.Lang.IllegalArgumentExceptionif format or size was not supported
Java.Lang.NullPointerExceptionif size was null

Remarks

Get the stall duration for the format/size combination (in nanoseconds).

format should be one of the ones returned by StreamConfigurationMap.GetOutputFormats.

size should be one of the ones returned by StreamConfigurationMap.GetOutputSizes(int).

A stall duration is how much extra time would get added to the normal minimum frame duration for a repeating request that has streams with non-zero stall.

For example, consider JPEG captures which have the following characteristics:

  • JPEG streams act like processed YUV streams in requests for which they are not included; in requests in which they are directly referenced, they act as JPEG streams. This is because supporting a JPEG stream requires the underlying YUV data to always be ready for use by a JPEG encoder, but the encoder will only be used (and impact frame duration) on requests that actually reference a JPEG stream.
  • The JPEG processor can run concurrently to the rest of the camera pipeline, but cannot process more than 1 capture at a time.

In other words, using a repeating YUV request would result in a steady frame rate (let's say it's 30 FPS). If a single JPEG request is submitted periodically, the frame rate will stay at 30 FPS (as long as we wait for the previous JPEG to return each time). If we try to submit a repeating YUV + JPEG request, then the frame rate will drop from 30 FPS.

In general, submitting a new request with a non-0 stall time stream will not cause a frame rate drop unless there are still outstanding buffers for that stream from previous requests.

Submitting a repeating request with streams (call this S) is the same as setting the minimum frame duration from the normal minimum frame duration corresponding to S, added with the maximum stall duration for S.

If interleaving requests with and without a stall duration, a request will stall by the maximum of the remaining times for each can-stall stream with outstanding buffers.

This means that a stalling request will not have an exposure start until the stall has completed.

This should correspond to the stall duration when only that stream is active, with all processing (typically in android.*.mode) set to FAST or OFF. Setting any of the processing modes to HIGH_QUALITY effectively results in an indeterminate stall duration for all streams in a request (the regular stall calculation rules are ignored).

The following formats may always have a stall duration:

The following formats will never have a stall duration:

All other formats may or may not have an allowed stall duration on a per-capability basis; refer to Android.Hardware.Camera2.CameraCharacteristics.RequestAvailableCapabilities for more details.

See Android.Hardware.Camera2.CaptureRequest.SensorFrameDuration for more information about calculating the max frame rate (absent stalls).

[Android Documentation]

Requirements

Namespace: Android.Hardware.Camera2.Params
Assembly: Mono.Android (in Mono.Android.dll)
Assembly Versions: 0.0.0.0