Create WinUI build config

[lukasf]

This PR adds a true WinUI build config:

• Use WinUI DispatcherQueue and DispatcherTimer to allow smooth subtitles even on WinUI
• Added file name APIs to FFmpegMediaSource and FrameGrabber
• Disabled BasicVideoEffect in WinUI build

Currently, this uses a dynamic detection of WinUI availability. The same dll can be used on a pure Desktop/Win32 app without WinUI, e.g. for pure transcoding scenarios, etc. Not sure if this is the best approach though.

Also, I try to get the main window from the current thread on WinUI, to decide if HDR shall be used or not. This won't work reliable if we have multiple windows on the same thread (which is supported on WinUI). If we want to allow the user to specify the target window, we'd have to add either a HWND (IntPtr) or WindowId type parameter to the config class.

Open questions:

How do we want to package this? We could put both UWP and WinUI/Desktop into a single NuGet package. Or we create separate packages for each target platform.

Also, shall we continue with dynamic detection of WinUI? Or shall we rather create separate builds for WinUI and Win32/Desktop (without WinUI)? It might be best to create separate builds right away, to avoid having to split up again at a later point.

[lukasf]

I have been thinking if we should merge this one to master already? It is our de-facto main branch already, we are just finalizing and bug fixing the 2.0 release.

It is a bit annoying always having to set the target of new PRs manually.

[brabebhin]

It's fine with me, we should merge the audio effect fix first.

We've also kept this branch long enough, and we're not releasing from master anyways.

[softworkz]

I have been thinking if we should merge this one to master already? It is our de-facto main branch already, we are just finalizing and bug fixing the 2.0 release.

I've been wondering why you haven't done so yet 😆

You could branch off from master before merging to have a "1.x servicing branch". Should there be a need for any security fix or important update to 1.x, it could be done in that branch.

[brabebhin]

It is unlikely we will be supporting the 1.0 version for too long, and updating to 2.0 is pretty trivial, just minimal API changes.

We don't have the man power for supporting 2 versions.

So I'm all for merging and kicking off preparations for the official 2.0 release.

In fact the 2.0 release will fix the infamous lifecycle requirements with a global variable which is the source of the majority of the complaints.

[softworkz]

I don't mean to actively maintain two versions. I simply meant to create a branch from the 1.x state onto which a contributor could submit a PR in case there's a severe reason. Whether this would lead to a fix release of 1.x or not, would be still up to your decision. But it would allow an 1.x user to submit a fix which other 1.x users could pick up (assuming all are doing their own builds).

[softworkz]

updating to 2.0 is pretty trivial, just minimal API changes.

Doesn't it require to use ffmpeg 7?

[brabebhin]

It does require ffmpeg 7. But for most people this will be handled by nuget.

[brabebhin]

anyways, I created the branch legacy/master-v1 at the current tip of master to mark this milestone, so anyone needing the current snapshot of master can check it out.

[softworkz]

Great! Probably it won't be needed, but in case someone has to PR something for this version, it's nice when it's there.

[huynhsontung]

It's finally merged! Thank you!