Is activeLockedVideoFrameDuration supported on iPhone 16 Pro? Hardware or iOS limitation?

Media Technologies Photos & Camera
raythor OP
Created
Replies 1
Boosts 0
Views 56
Participants 1

Hello Apple AVFoundation team,

Could you clarify the supported iPhone models and OS versions for standalone locked video frame duration using AVCaptureDeviceInput.activeLockedVideoFrameDuration?

The API is documented as available from iOS 26.0, but I understand that OS availability alone does not mean every camera device/configuration supports it. I have read the API documentation and the DTS reply in iPhone 17 Pro's Genlock feature, but could not find a model compatibility list for the standalone locked-duration API.

Scope: I am investigating actual capture timing for multi-iPhone motion capture. This question is about locking each camera's frame period using its internal timing, without an external genlock accessory. I am not asking about encoding a constant-frame-rate file, ordinary equal min/max frame durations, timecode metadata, or synchronizing the first exposure across phones.

Physical-device test
  • iPhone 16 Pro, iOS 26.2 (23C55).
  • Built with Xcode 26.3 and the iOS 26.2 SDK.
  • One AVCaptureSession, one physical rear .builtInWideAngleCamera input, and one AVCaptureVideoDataOutput.
  • 8-bit SDR 420v formats, tested at 1920 x 1080 and 3840 x 2160, each at 30 and 60 fps.
  • Auto video frame rate disabled; no spatial video capture or multicam session.
  • Manual exposure approximately 2 ms, shorter than half a frame at both tested rates.
  • The session is running and delivering frames. Two separate probe runs produced the same results, including capability readbacks after a settling period.

For all four tested configurations:

input.isLockedVideoFrameDurationSupported = false
device.minSupportedLockedVideoFrameDuration = kCMTimeInvalid
input.activeLockedVideoFrameDuration = kCMTimeInvalid
device.isVideoFrameDurationLocked = false

Ordinary activeVideoMinFrameDuration and activeVideoMaxFrameDuration can both be set to the requested CMTime(value: 1, timescale: 30) or CMTime(value: 1, timescale: 60), and frames are delivered. This is only a configuration readback, not a claim of exact capture timing in the ordinary mode.

The app directly queries the public support properties; it has no model whitelist. It does not attempt to set a valid locked duration when support is false, as the documented setter contract would reject that. These tests cover the selected formats, not every camera/format on this phone.

Questions
  1. Which iPhone models support this standalone API? In particular, is false expected on iPhone 16 Pro? Is there an official compatibility list covering iPhone 13/14/15/16 and iPhone 17 models?
  2. Is the iPhone 16 Pro result a hardware capability restriction, an iOS 26.2 limitation/known issue, or a configuration requirement? Is there a released iOS version that enables this on iPhone 16 Pro, or is newer hardware required?
  3. What is the minimum supported capture configuration and correct time to query support? Are there restrictions involving the physical versus virtual camera input, pixel format, SDR/HDR, or exposure mode that could explain this result? If so, which configuration should be tested before concluding that the device does not support it?
  4. On supported hardware, can this standalone lock be enabled without an external accessory or a special entitlement, independently of follow(_:videoFrameDuration:delegate:)?

Relevant documentation:

I can provide a focused reproducer if needed. Thank you for clarifying the device requirements and whether an OS upgrade can change the result.

Replies  1
Boosts 0
Views  56
Participants  1
raythor OP

Update: I have now tested the same demo version (0.1.0, build 1) on a physical iPhone 17 Pro Max running iOS 26.4.1 (23E254). Two independent probe runs succeeded in all four tested configurations.

The app configures only activeLockedVideoFrameDuration; it does not call follow(_:videoFrameDuration:delegate:) or configure any external synchronization device. This is a test of the standalone lock, with no external genlock reference.

Capture setup: one physical rear .builtInWideAngleCamera, one AVCaptureSession, one AVCaptureVideoDataOutput, 8-bit SDR 420v, manual exposure approximately 2 ms, auto video frame rate disabled, no multicam or spatial-video output.

The following are actual public-API readbacks after configuration and a settling period:

Format       FPS  Supports  Locked  Active duration  Frames R1 / R2
1920 x 1080   30  true      true    1/30 s           32 / 33
1920 x 1080   60  true      true    1/60 s           64 / 64
3840 x 2160   30  true      true    1/30 s           32 / 33
3840 x 2160   60  true      true    1/60 s           64 / 65

Both runs have the displayed support, lock state and active duration. The requested duration was 1/30 s for 30 fps or 1/60 s for 60 fps, matching the active-duration readback.

Common log values for all eight results:

input.isLockedVideoFrameDurationSupported = true
device.minSupportedLockedVideoFrameDuration = CMTime(value: 1, timescale: 60)
input.activeLockedVideoFrameDuration = requested duration (exact rational readback)
device.isVideoFrameDurationLocked = true
device.isAutoVideoFrameRateEnabled = false
targetAllowed = true
configurationError = nil

Frame counts above only demonstrate delivery during the scheduled diagnostic window; they are not precise frame-rate measurements. These probes establish that the standalone API can be enabled and frames are delivered. They do not establish long-term locked capture timing, optical exposure accuracy, or synchronization between phones. A separate short recording was in ordinary mode, so I am not using that recording's timestamps to claim locked-mode precision.

For comparison, the earlier iPhone 16 Pro / iOS 26.2 (23C55) tests with the same demo version and four capture configurations returned:

input.isLockedVideoFrameDurationSupported = false
device.minSupportedLockedVideoFrameDuration = kCMTimeInvalid
input.activeLockedVideoFrameDuration = kCMTimeInvalid
device.isVideoFrameDurationLocked = false

Both the phone model and OS version differ in this comparison, so these results alone cannot determine whether the iPhone 16 Pro restriction is hardware-dependent or OS-dependent. Could Apple clarify whether this is the expected model boundary, and whether any released OS version enables the standalone lock on iPhone 16 Pro?