Comments (10)
Bounty completed.
References
Repositories
- MonoGame.Tool.FFMpeg: https://github.com/MonoGame/MonoGame.Tool.FFmpeg
- MonoGame.Tool.FFProbe: https://github.com/MonoGame/MonoGame.Tool.FFprobe
- MonoGame.Tool.BuildScripts: https://github.com/MonoGame/MonoGame.Tool.BuildScripts
Build Statuses with artifacts
- FFMpeg: https://github.com/MonoGame/MonoGame.Tool.FFmpeg/actions/runs/8898492571
- FFProbe: https://github.com/MonoGame/MonoGame.Tool.FFprobe/actions/runs/8898493268
Note
Both FFMpeg and FFProbe are built with customized flags when the ./configure
script is called. Each repository has a shared config file and a platform specific config file that's used in each build. The shared config file contains all the flags used for which encoders, decoders, and muxers to include when building the binaries.
- FFMpeg Shared Config: https://github.com/MonoGame/MonoGame.Tool.FFmpeg/blob/main/ffmpeg.config
- FFProbe Shared Config: https://github.com/MonoGame/MonoGame.Tool.FFprobe/blob/main/ffprobe.config
After looking through the monogame repository and speaking with harry, the build was customized to only use the encoders needed that the content pipeline used, as well as muxers, but all standard decoders are included. If additional encoders, decoders, or muxers are needed in future versions, just edit the appropriate config file for each and add the one you need. This was done in effort to reduce the total size of each binary being distributed by only including what was needed instead of the entire kitchen sink.
You can determine the flags for which ones are available by executing the ./configure
script for ffmpeg with the following flags
# View available encoders
./configure --list-encoders
# View available decoders
./configure --list-decoders
# View available muxers
./configure --list-muxers
from monogame.
Good job on completing the first bounty!
from monogame.
Progress update on bounty
Customized compiling
I have the configuration setup to compile ffmpeg and ffprobe using only the encoders and muxers used in the MonoGame repository instead of the usual kitchen sink approach. This cuts the size of the ffmpeg binary per platform from ~30MB to ~16MB, almost a 50% reduction in distribution size for each binary.
Linux Compilation
I have a script working to build for linux-x64. This one wasn't so bad to do, it just kind of worked because Linux is Linux
Windows Compilation
Windows is a little tricker. Since this was to be setup the same way as the MonoGame.LIbrary.* repos, I assumed everything needed to be statically linked and pass the same dependency checks as the library tests. Compiling ffmpeg on windows is dumb and there is a lot of setup that needs to happen. Alternatively, there is a cross-compilation option where the WIndows executable can be built from Linux, which is far easier to setup and do, and I have compile successfully with that method.
Mac Compilation
Mac, weirdly enough, is where all of the issues are coming from. I can compile for x86_x64 on Mac, no problem. However, compiling for arm64(aarch64 ) is a bit more of an involved process and it's constantly failing. In order to ensure everything is statically linked that means all dependent libraries need to be compiled for arm64 as well. The GitHub macos-latest
runner is an x86_x64 architecture, which means I have to setup llvm toolchain for compilation for every dependency that that builds up to the ffmpeg build. I've hit several roadblocks with this and it's the single cause of why this hasn't been completed yet.
TL;DR
- Reduced size of each platform binary by roughly 50%
- linux-x64, win-x64, macos-x64 build scripts pretty much done
- macos-arm64 is a pita and is pushing me past the initial ETA
I'm considering looking into the option of having the all binaries compiled on linux using cross platform compilation options, but need to get the setup for the mac tool chain on Linux figured out first. Doing this would significantly make things easier for all builds and then the final mac universal binary can be combined with lipo or the dotnet tool can be packaged with separate x64 and arm64 mac binaries
from monogame.
MonoGame needs to package up ffmpeg and ffprobe for content compilation.
📃Full details
In order to improve the maintainability of the 3rd party dependencies and tooling, we are trying to prepare the compilation and packaging for ffmpeg and ffprobe as per #8124.
Whats expected from this task is to build 3 repositories, one for shared tooling build scripts and two repositories for the ffmpeg and ffprobe executables, see "Expected delivery content*" bellow for clearer details.
The MonoGame Foundation wishes to accelerate this transition by offering a paid opportunity to undertake this task.
🔒 Bounty status
Locked for @AristurtleDev to complete. 🔒
💰 Bounty
$360,00 USD (Three hundred and sixty US dollars).
✋ Requirements to apply
Standard requirements from our generic bounty requirements.
📦 Expected delivery content
MonoGame.Tool.BuildScripts repository that can be used as a shared scripts repository for all future tooling (Similary structured as MonoGame.Library.BuildScripts).
MonoGame.Tool.FFMpeg repository containing the packaging scripts for the ffmpeg executable. (Similary structured as MonoGame.Library.FreeType).
- Should build the latest stable version of ffmpeg.
- Should be packaged into a dotnet tool
mgcb-ffmpeg
.- Should upload the nuget to GitHub packages on build.
MonoGame.Tool.FFProbe repository containting the packaging scripts for the ffprobe executable. (Similary structured as MonoGame.Library.FreeType).
- Should build the latest stable version of ffprobe.
- Should be packaged into a dotnet tool
mgcb-ffprobe
.- Should upload the nuget to GitHub packages on build.
The C# coding style should match the standard Microsofts C# coding style guideliness.
The build scripts in all repository should use CAKE Frosting.
The CI system in all repositories should use GitHub Actions.
📅 Delivery timeline
As soon as possible.
@harry-cpp What's the goal/intention behind having statically linked dependencies?
from monogame.
@harry-cpp What's the goal/intention behind having statically linked dependencies?
For the MonoGame.Library.X repos this ensures that each dependency is independent, ie. multiple dependency can use different versions of the same library that they need.
For the MonoGame.Tool.X repos, it does not need to statically link against all of its dependencies, but in that case, all the dependencies would need to be included next to the executable.
from monogame.
Given that ffmpeg/ffprobe are in MonoGame.Tool repos, with the information you provided, I assume there is no static linking constraint for ffmpeg/ffprobe?
I understand the MonoGame.Library constraint and it makes sense.
from monogame.
Given that ffmpeg/ffprobe are in MonoGame.Tool repos, with the information you provided, I assume there is no static linking constraint for ffmpeg/ffprobe?
I understand the MonoGame.Library constraint and it makes sense.
Even if including the dynamic linked libs used by ffmpeg along side the binaries, those libs would need to be built statically for the operating system and/or architecture of the ffmpeg binary they support correct?
So statically linking them with the binary just seemed like the appropriate thing. If this is not the case, I can switch up how the builds are working
from monogame.
Even if including the dynamic linked libs used by ffmpeg along side the binaries, those libs would need to be built statically for the operating system and/or architecture of the ffmpeg binary they support correct?
Adding all the dylibs/dlls etc in a single downloadable nuget package (i.e. provide them statically not the compile-time static link) seems like the goal? which is what I would imagine a default brew
/configure
scripts would do? @harry-cpp
/*
For the bounty amount/effort, it feels like a whole lot more to strive for (literal) static linking with very little (or negative) benefit IMO. Just being able to see ffmpeg/ffprobe sources in a secure / verifiable / reproducible build alone will go a long way; having them be nuget packageable/updateable is even better.
*/
from monogame.
Even if including the dynamic linked libs used by ffmpeg along side the binaries, those libs would need to be built statically for the operating system and/or architecture of the ffmpeg binary they support correct?
Yes, all the dependencies would need to be included.
from monogame.
Yes, all the dependencies would need to be included
Yea so if all dependencies would need to be included, and those dependency libs would need to be compiled as statically linked, then might as well throw in the --enable-static configure flag for ffmpeg build. Then the tool is distributing just the binaries and not thr binaries and all its dependencies
from monogame.
Related Issues (20)
- Issue with GetData/SetData as of 2024 HOT 2
- `DrawableGameComponent.Initialize` Does Not Behave How XNA Documentation Describe It HOT 1
- [PAID BOUNTY][LOCKED] A shared base for public and console repos
- AL lib throws unclosed device warning on proper game exit HOT 4
- Variable rate shading HOT 2
- [Urgent security issue] FreeImage arbitrary code execution vulnerability HOT 2
- tu-clausthal link does not exists HOT 2
- Getting started page is not working HOT 2
- SpriteBatch With Custom Effects and Per-Sprite Data HOT 2
- Links in Footer not working (Website)
- Visual Studio extension doesn't build anymore HOT 2
- Separate interfaces and platform-specific realizations HOT 2
- Getdata<T> allocates an extra array of T[] HOT 3
- Mitigate null reference exceptions via better communication HOT 1
- Debian Wine Setup: command not found: wine64 HOT 3
- Joystick.LastConnectedIndex does not update properly
- [PAID BOUNTY] A better 2D onboarding tutorial HOT 6
- [PAID BOUNTY] A better 3D onboarding tutorial HOT 3
- Support video in Android
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from monogame.