search

ffmpeginteropx / FFmpegInteropX

FFmpeg decoding library for Windows 10 UWP and WinUI 3 Apps
Apache License 2.0
212 stars 53 forks source link

Create WinUI build config #364

Closed lukasf closed 2 months ago

lukasf commented 1 year ago

This PR adds a true WinUI build config:

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 commented 3 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

Doesn't it require to use ffmpeg 7?

brabebhin commented 2 months ago

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

brabebhin commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

It's finally merged! Thank you!