Request for Corresponding Source and Build Information for LGPL libmpv Windows Build

[Tsukuyomi82]

Hello,

I am developing SimMedia, a proprietary Windows media player under the EF Softworks name, and I am evaluating the official LGPL Windows x64 build of libmpv for commercial distribution.

The specific artifact is:

"libmpv-v0.41.0-dev-gd94d09581-38104846940-x86_64-w64-mingw32-lgpl.zip"

I have reviewed the publicly available build scripts and source repositories, but I have not been able to establish the complete corresponding source and build information for this specific binary.

Could you please clarify whether the following information is available?

1. The exact source revisions and applied patches for the statically linked dependencies in the build container.
2. The resolved source revisions for FFmpeg, LuaJIT, subrandr, mujs, and their relevant dependencies.
3. Corresponding source and build information for generated headers and the bundled libbluray JAR.
4. The applicable license texts, copyright notices, and instructions for obtaining the corresponding source.

If a complete corresponding-source archive or build manifest is already available, a link would be greatly appreciated.

My goal is to comply with the applicable LGPL and third-party license obligations while distributing SimMedia as a proprietary application.

Thank you for your time and for maintaining mpv.

Best regards,

EF Softworks

[kasper93]

If a complete corresponding-source archive or build manifest is already available, a link would be greatly appreciated.

It's not summarized, but all information are available in build log, which is part of the artifact name. For example for the artifact you listed the job id is 38104846940, which is https://github.com/mpv-player/mpv/actions/runs/38104846940

From there you can check the build image, (built-by https://github.com/BtbN/FFmpeg-Builds), there is exact image hash used in docker pull log, where you can lookup all dependencies of ffmpeg itself. In the log there are also listed deps the we build on top.

If you need full summary of all versions and dependencies, patches are welcome, CI job could summarize in artifact description what was used, without needing to inspect logs.

Note that we don't take responsibility for the compliance of those build with your software. It's best effort, and while to the best of my knowledge things there are configured correctly for LGPL, it's moving target and bugs/errors may happen at any time, especially that we use externally provided docker image from BtbN. However, he also publish builds of ffmpeg done with those images, and they are commonly used.

[Tsukuyomi82]

Thank you very much for the detailed explanation and for pointing me to the CI build logs!

I'll review the build logs and dependency information you mentioned to determine what is still needed for LGPL compliance.

I really appreciate your help and your offer to provide additional build information. If I find any specific gaps, I'll follow up with the details.

Thanks again!

[Andarwinux]

BtbN/FFmpeg-Builds#665
BtbN/FFmpeg-Builds#661
BtbN/FFmpeg-Builds#678

I suspect these are all LLM

[kasper93]

What is the end goal here...

[Tsukuyomi82]

Thank you for the quick and detailed response!

My goal is to distribute SimMedia, a proprietary commercial Windows media player, through the Microsoft Store while fully complying with the LGPL and all applicable third-party licenses.

I would like to use the official LGPL Windows x64 libmpv build without having to rebuild the entire dependency stack myself, if possible.

A summary of the exact dependency versions, source revisions, applied patches, and build configuration in the artifact description would be extremely helpful.

I understand that the project does not guarantee LGPL compliance for these builds, and I will independently review the licensing requirements before distribution.

Thank you again for your help!

[Tsukuyomi82]

Thank you for helping us locate the CI evidence for run 38104846940.

We are preparing SimMedia, a proprietary commercial media player for Windows, and are evaluating the LGPL-compatible libmpv build.

We noticed that the recovered build recipe enables Chromaprint with FFT_LIB=fftw3, and the artifact contains FFTW-related strings. However, we have not confirmed whether FFTW3 is actually linked into the distributed DLL.

Since SimMedia does not require audio fingerprinting, could you confirm whether Chromaprint and FFTW3 are included in this build?

If so, would it be possible to provide a Windows x64 LGPL build without them, for example by using FFmpeg's --disable-chromaprint option? Alternatively, guidance on the necessary recipe changes would be very helpful.

We would also appreciate any available corresponding source revisions, patches, effective build options, and dependency license information needed for redistribution.

Our goal is to retain normal playback, subtitles, GPU rendering, and network playback while complying with the applicable LGPL requirements.

Thank you again for your time and assistance.

[philipl]

As you are ultimately legally responsible for your own LGPL compliance, it is fundamentally unwise to rely on an uncontracted third party to provide the binary components you are trying to distribute. There is no guarantee that a binary artefact you find on the internet is fully compliant, nor that it will remain so in the future. The only safe practice is for you to build all your required artefacts from source, with you in full control of the source and build flags used. Relying on the best efforts of third parties with no legal obligation to you is not wise.

[Tsukuyomi82]

Thank you very much for taking the time to share your advice.

I completely understand your point. As the developer and distributor of SimMedia, I recognize that the responsibility for LGPL compliance ultimately rests with me, and that relying on third-party binaries without full control over their build configuration introduces unnecessary risks.

Based on your advice, I have decided to move forward with building and maintaining our own LGPL-compatible libmpv and FFmpeg binaries from source, with carefully controlled dependencies and build options.

I also want to express my appreciation for the work you and the other mpv contributors have put into this project. As an independent developer, having the opportunity to learn directly from experienced contributors means a great deal to me.

Thank you again for your guidance. I will take it seriously as I continue developing SimMedia.

[kasper93]

If so, would it be possible to provide a Windows x64 LGPL build without them, for example by using FFmpeg's --disable-chromaprint option? Alternatively, guidance on the necessary recipe changes would be very helpful.

Yes, this can be done as paid work. Customized builds and pipelines go beyond the community support we provide here, but we're open to discussing terms if you'd like to pursue it.

[Tsukuyomi82]

Thank you very much for your response and for offering to discuss a customized build.

I sincerely appreciate your time and willingness to help.

For now, I have decided to try building and maintaining the LGPL-compatible libmpv binaries myself, so that I can take responsibility for the build configuration and redistribution requirements.

If I encounter difficulties that require professional assistance, I would be happy to discuss a paid engagement in the future.

Thank you again for your guidance and for your contributions to mpv. It has been a valuable experience to communicate directly with the project's developers.

[rubyFeedback]

Is this some LLM-generated interaction? It's such a weird ... dialogue really. The software cited by the threadstarter is mentioned at the least seven times in total. That's really weird for a human to want to do so. I mean ... that should have already been clear at the first or at most second mention to other humans, right? But having that seven times, with a structure in the "header" and "footer" that is almost identical. Or perhaps I am seeing ghosts, who knows.

[kasper93]

I'm almost certain this is an autonomous agent, which is building and app and assessing the scope of dependencies.

Or perhaps I am seeing ghosts, who knows.

No, you are right. No human would write like that, and even if someone used llm to translate/write the question, it wouldn't look like that. It's fully automated.