feat: Migrate to Media Foundation and get aot compatibility

[OleRoss]

Hi, I needed Native AOT (and trimming) compatibility for my Avalonia project. Unfortunately, this library does not provide AOT-compatible bindings. This is mainly due to

1. The use of DllImport
2. The use of COM APIs

Both can be solved, but require compromises:

1. Instead of DllImport, LibraryImport can be used, which is only available for >= net7.0
2. Instead of runtime-generated com APIs, net8.0 and above offer the capability to have source-generated com APIs.

Additionally, to make life a bit easier, I decided to use the Media Foundation APIs instead of DirectShow (the DirectShow APIs were already deprecated, and I felt like the COM API was a bit simpler).

I only tested the Windows changes so far.

This PR shows how this refactor can be done, and I hope it can be upstreamed at some point. I already know that this will be difficult because of the following limitations:

1. Windows XP and below are dropped
2. TargetFramework compatibility is now net8.0 and above.

I am happy to continue working on this PR if you are interested in such a huge change.
Or, if you want to go a different way, feel free to close the PR/adjust it to your needs.

P.s.

The only way I can see to support all target frameworks is to add the com-generated APIs as a separate CaptureDevice Type (in addition to the existing DirectShow device) and use LibraryImport conditionally.
However, I felt like this was too much trouble to go through.

Fixes #136, #163

[kekyo]

@OleRoss Thanks for the PR!

I think this is a great proposal. In particular, support for the Media Foundation API has long been identified as an issue.

Would it be possible to split these changes into the following two parts?

• Fixes to enable AOT support:
  If the attributes are only available in .NET 7.0 or later, I believe they can be isolated using #if. It might seem like a hassle, but I believe we still need this broad TFM support for a little while longer.
  • Please refer to Simplify target frameworks GitReader#3 (comment) for a summary of this topics.
  • Since SDK installations such as netcoreapp have been excluded from the Actions script, please restore them. To use older SDKs in a local environment, it’s easiest to use dotnet-install sctipt.
• Enabling Media Foundation support

MF API related:

• How everyone is using it? #29 (comment)
• How to detect if camera is being used by other applications? #15 (comment)

[OleRoss]

Hi @kekyo,
Thanks for taking a look at this. I have feared that standpoint on the TFM support :D

I read your comments and understand your stance, but personally, I feel the complexity is not worth it in the long run. And if supporting an old TFM makes it difficult to implement substantial performance/DX improvements for new projects, I feel like it's time to drop some.

But back to a solution to the actual issue:

My issue right now is that my code is using GeneratedComInterface to generate the previously runtime-generated COM interfaces. And I see no way to easily guard this behind a #if. And also when I used the CsWin32 lib to generate the bindings, I still depended on their useComSourceGenerators, which uses this attribute under the hood.

As a solution, I can see that would be to support Media Foundation for >= net8.0 only:

• if < net8.0 use the existing DirectShow code
• if >= net8.0 use the new Media Foundation code, making use of source generators

MacOS and Linux could just use conditional DllImport/LibraryImport attributes without relevant changes to the code.

This would enable a much cleaner separation of concerns.

I can also see a world where we use CsWin32 to generate bindings conditionally, depending on whether the source-generated COM wrappers are available. But they officially support net472 only. Maybe we are lucky and don't need newer features, and this still works up until net35, but I dont think that would be guaranteed.

[OleRoss]

To use older SDKs in a local environment, it’s easiest to use dotnet-install sctipt.

Out of interest, since I am not regularly developing with older TFMs, why do I need an older SDK? I can compile net35 with my net10/net11 SDK, right?