search

ffmpeginteropx / FFmpegInteropX

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

Introduce new NuGet package layout for v2.0 #418

Closed lukasf closed 6 months ago

lukasf commented 6 months ago

Finally I found the time to do the new NuGet Layout!

These are the new packages:

Other changes:

brabebhin commented 6 months ago

Integrated the ffmpeg desktop build with my app, works nice.

Good work!

brabebhin commented 6 months ago

Also works with net 8.

lukasf commented 6 months ago

@softworkz I also added a way to override the FFmpeg build dependency NuGet name and version (using e.g. a Directory.Build.props file). I thought this might come in handy, if devs want to compile against their own ffmpeg build, possibly with a different NuGet package name and version. Check the last commit.

softworkz commented 6 months ago

@softworkz I also added a way to override the FFmpeg build dependency NuGet name and version (using e.g. a Directory.Build.props file). I thought this might come in handy, if devs want to compile against their own ffmpeg build, possibly with a different NuGet package name and version. Check the last commit.

Thanks a lot for provisioning for that case.

Thanks again for merging my code contributions. This allowed me to consolidate and get me up to date (previously I had my changes based on an earlier version), so I'm almost equal now to the winui branch here - except for the vcxproj and nuget package building. All nuget packages have a different naming to avoid collisions/ambiguities. Right now I have a single PS script to call, which builds everything (except ffmpeg) and pushes it to an Azure DevOps package feed, Then I just need to update packages in the consuming projects and the DevOps builds are working fine without needing to take any extra steps. Given this high level of comfort achieved, I hope you'll understand that I don't want to touch this part again right now... 😉

But I'm sure it will be useful for others.

lukasf commented 6 months ago

Given this high level of comfort achieved, I hope you'll understand that I don't want to touch this part again right now... 😉

Sure, I fully understand that. Just wanted to mention it.

lukasf commented 6 months ago

The last thing missing here is moving the BasicVideoEffect to a separate NuGet package, so we don't have a dependency on Win2d on our UWP main packages. I will try to do that in the next days.

Oh and by the way, should we completely drop ARM (32 bit) support? It's really a dead platform, only used by WindowsPhone back in the days. On the Desktop build, I had to remove it anyways, because WinUI does not support it. Maybe we should drop it on UWP as well.

I even thought a bit about dropping x86 as well. Percentage of 64 bit OS on Windows has gone up from 99.7% to 99.9% last year. But maybe we should still leave that decision to app developers, not force it through our lib (yet). Maybe in a few years we can consider to stop delivering it.

brabebhin commented 6 months ago

How about moving the effect to the c++ sample instead?

The effects are broken in winui 3/cswinrt, i don't think it's worth the hustle and the ensuing bug reports.

I agree with dropping ARM, i don't think there's any devices running the 32 bit version anymore.

softworkz commented 6 months ago

Oh and by the way, should we completely drop ARM (32 bit) support? It's really a dead platform, only used by WindowsPhone back in the days.

I think yes, absolutely!

I even thought a bit about dropping x86 as well. Percentage of 64 bit OS on Windows has gone up from 99.7% to 99.9% last year. But maybe we should still leave that decision to app developers, not force it through our lib (yet). Maybe in a few years we can consider to stop delivering it.

I'm not sure about those figures. I've seen a statistics table which indeed says 0.1%, but I doubt it a bit. Even Windows 7 still has a share of 3% (https://en.wikipedia.org/wiki/Template:Windows_usage_share) - which says nothing about bitness of course. But there are many devices (for example low-cost tablets) with Windows 10 which were shipped with 32bit OS (to save RAM and storage requirements) and users of such devices won't typically upgrade to 64bit OS versions (which would severely degrade usability), neither can I imagine that all those devices have been disposed. There are Windows 10 32bit versions which are still within the official Microsoft support cycles and components (like WebView2 are still made available as 32bit redistributables).

Just recently I wondered whether we would even need to provide a 32bit version of our Windows app, and my conclusion was yes, we should.

Lastly, it's not only a matter of platform bitness. An application developer may have reasons (like 3rd party libs not available in 64bit, memory constraints or whatever) to publish an application in a 32bit variant only. So I think that 32bit has still a little while to stay.

lukasf commented 6 months ago

ARM builds removed. I left the option in the build scripts, just not using it in the default builds (and not in our NuGet packages). But if someone desperately wants, they can still do an ARM builds using our build scripts.

I agree that removing x86 would be too early. We are not there yet.

About the video effects, I will only make an UWP package (until video effects work in WinUI, which is improbable to happen within the next five years).