So, the current pull request lacks of one important thing for OSX - change of OnEnumerateDescriptors' signature since on Apple devices access must be requested first, that's an asynchronous operation.

MEMO: If sync-over-async is not going to be a fatal problem, we could add Obsolete and move to a new asynchronous method like Task<CaptureDeviceDescriptor[]> OnEnumerateDescriptorsAsync(). I think it might be a good idea to encourage this.

@YohDeadfall Perhaps a brief description of how to test it on a Mac would be better for people to feel free to try it 😄

Added it, but @kiminuo can provide a little bit more on it since he helped me originally.

I simply ran

dotnet run -f net6.0 --project ./samples/FlashCap.Avalonia/FlashCap.Avalonia

then an Avalonia application is supposed to appear. One selects a camera and that's basically it.

If you have multiple .NET versions on your machine, it's good to add global.json:

{
  "sdk": {
    "version": "6.0.100",
    "allowPrerelease": false,
    "rollForward": "latestFeature"
  }
}

but I'm not sure what .NET versions should be supported so it's just a general remark.

I wasn't even sure if the Avalonia version would actually work on the Mac, so thanks for the help!

It works perfectly on all platforms and even might work on Tizen. At least there's an issue on it and some work is being done.

@YohDeadfall Not much of a response, is it running with no problems at all? :)
If there is a problem, I'm thinking I could release it, but what do you suggest?
There is a possibility that if it is not released, people may not actually try to use it.

The problem here is that it crashes trying to process a frame. @kiminuo did testing, but you know, when development happens by one developer and testing by another it takes too much time and energy.

There's a Xamarin project for barcode scanning I can use to make a debug version with a single hard coded characteristic and the most simple image format. Then if it runs without any issue, we can publish it and bring features later when there's some interest.

Is it okay?

Oh... I would have been able to debug it myself if I could get a Mac...

@YohDeadfall Hi, I am now trying to extend the transcode type for this issue.

Specifically, a modification that would change the transcodeIfYUV argument in the code from a boolean type to an enumerated type. So, no technical changes, but widespread changes in the FlashCap project.

So, after much thought, I'd still like to accept this PR once and for all before this changing, what do you think?

I'm also wondering if it would be better to put a notation in the documentation that says "This is experimental and behavior verification and modifications are welcome" so that people who want to implement captures can see it and try it out.

@YohDeadfall Hi, I am now trying to extend the transcode type for this issue.

Specifically, a modification that would change the transcodeIfYUV argument in the code from a boolean type to an enumerated type. So, no technical changes, but widespread changes in the FlashCap project.

So, after much thought, I'd still like to accept this PR once and for all before this changing, what do you think?

I'm also wondering if it would be better to put a notation in the documentation that says "This is experimental and behavior verification and modifications are welcome" so that people who want to implement captures can see it and try it out.

Here's a start you might want to consider be698df

The current problem is that when this pull request is tested it causes a crash due to finalization of an AVCaptureDeviceDiscoverySession, but it is created in only the one place and with an using block controlling its lifetime.

If someone is able to continue on that, I would be happy to provide any other information and help in dealing with it. But for now I have no Mac device and cannot test it myself.