Skip to content

Added method to request a specific camera unique identifier.#37

Closed
dsmurfin wants to merge 1 commit intoMetalPetal:masterfrom
dsmurfin:Request-Camera
Closed

Added method to request a specific camera unique identifier.#37
dsmurfin wants to merge 1 commit intoMetalPetal:masterfrom
dsmurfin:Request-Camera

Conversation

@dsmurfin
Copy link
Collaborator

@dsmurfin dsmurfin commented Mar 6, 2022

No description provided.

@YuAo
Copy link
Member

YuAo commented Mar 8, 2022

For #37, #38 and #41

I think the current form of the API is not suitable for these tasks.

For example:

  • When user specifies both position and uniqueID, the position info is just ignored.
    Maybe we should use a enum here.

If we are going to add these features, we'd better redesign the related API.

@dsmurfin
Copy link
Collaborator Author

dsmurfin commented Mar 8, 2022

If we are going to add these features, we'd better redesign the related API.

I agree. I was attempting to resolve this feature in a way that did not break existing implementations.

An enum would be a better solution here. It might be desirable to provide a fallback option:

enum DeviceSelection {
   case .position(position: Position)
   case .device(uniqueID: String)
   case .device(uniqueID: String, format: AVCaptureDevice.Format)
   case .device(uniqueID: String, fallback: Position)
   case .device(uniqueID: String, format: AVCaptureDevice.Format, fallback: Position)
}

@YuAo
Copy link
Member

YuAo commented Mar 9, 2022

It might be desirable to provide a fallback option.

This is a little confusing:

  • Is the fallback option only used when the device with that uniqueID cannot be found? or the format is not supported or we have any error switching to that device?
  • What if there's an error switching to the fallback device? Which error should we report: the error switching to the fallback device or the error switching to the requested device?

The no-fallback approach seems to be clearer and simpler. If there's an error switching to a requested device, we can catch that error and decide whether we should fallback to another device or directly present that error to our user.


How about this:

Just add a switchToVideoCaptureDevice(_ device: AVCaptureDevice) method.

If you don't care about a particular device you can still use switchToVideoCaptureDevice(with: AVCaptureDevice.Position, preferredDeviceTypes: [AVCaptureDevice.DeviceType]).

If you need to switch to a particular device you can use switchToVideoCaptureDevice(_ device: AVCaptureDevice). You can also set the active format after switching the device:

try camera.switchToVideoCaptureDevice(device)
try device.lockForConfiguration()
device.activeFormat = ...
device.unlockForConfiguration()

This maintains the simple interface for common use and exposes a way for capture device customization.

@dsmurfin
Copy link
Collaborator Author

dsmurfin commented Mar 9, 2022

Just add a switchToVideoCaptureDevice(_ device: AVCaptureDevice) method.

This makes more sense, it also removes the need for the preferredDeviceTypes which of course are not required in this context. The same principle could also be applied to audio instead of #38.

I am a bit tight for time over the next few days, but I will look to rework some of these PRs over the next week or so as per our discussions.

@YuAo
Copy link
Member

YuAo commented Mar 10, 2022

I've implemented my proposal here #47. @dsmurfin Can you do a code review when you have time?

@dsmurfin
Copy link
Collaborator Author

Amazing, thanks! Yes, I will do that over the weekend if not before.

@YuAo YuAo closed this Mar 12, 2022
@dsmurfin dsmurfin deleted the Request-Camera branch April 6, 2024 12:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants