[FEATURE] Add Support for macOS, Windows, Linux, Web

[YazeedAlKhalaf]

Description
New Feature Request

I think it would be great if the plugin supports all the other platforms that Flutter supports.

Windows is a little bit behind but the others work like a charm. I think it would open new possibilities.

[YazeedAlKhalaf]

Any Updates?

[Driaan]

Any updates?

[tanersener]

Can someone elaborate why we need this feature?

ffmpeg binaries for Linux/Mac/Windows are already available at ffmpeg.org. Isn't it possible to run them using a plugin like process_run?

We also have ffmpeg.wasm and ffmpeg.js for WEB. I haven't tried using them but I guess there should be a way to use them in flutter?

[YazeedAlKhalaf]

It would be better if you can do one execute command for all platforms. The method you are proposing is useful in a project for desktop only. Our idea is to have support for Windows Mac Linux and Web natively from your awesome plugin.

Windows is not stable so might be postponed.

Mac is in beta but is reliable.

Linux I don’t know about it much.

Web is great 🤗.

So I hope you can figure a way of making this plugin work on platforms beyond iOS and Android

[YazeedAlKhalaf]

Any updates?

[tanersener]

I don't have time to work on this right now.

[tanersener]

Looked at the documentation about these platforms. web is in beta, Linux and Mac is in alpha, Windows is in technical preview. Which means only web is mature enough.

[stuartmorgan]

web is in beta, Linux and Mac is in alpha, Windows is in technical preview. Which means only web is mature enough.

Linux and macOS alpha was the point where the plugin APIs for each of those platforms were declared stable, so if there are things blocking the development of this plugin for either platform please file Flutter issues.

[YazeedAlKhalaf]

Ah okay, great. Let's start with the web platform.

[tanersener]

Linux and macOS alpha was the point where the plugin APIs for each of those platforms were declared stable, so if there are things blocking the development of this plugin for either platform please file Flutter issues.

Being able to file an issue doesn't solve anything. Flutter documentation says In general, we don’t recommend releasing a desktop app until desktop support is stable. I think the message is pretty clear.

There are still grey areas in the documentation of desktop platforms and unfortunately there are not any native Linux/macOS plugins out there to analyse and clarify those points. I respect your opinion but let me manage my time myself. As I told you before, I have limited time to maintain this project.

And yes, web is beta but developing a native web plugin is not simple. Honestly, I haven't seen any native web plugins.

Why don't you share the plugins you know that support web and/or desktop platforms? So, anyone who wants to develop support for those platforms can use them as reference.

[stuartmorgan]

Being able to file an issue doesn't solve anything.

If there are issues blocking the development of plugins, filing them is how we'll know what those issues are in order to address them.

Flutter documentation says In general, we don’t recommend releasing a desktop app until desktop support is stable. I think the message is pretty clear.

The reason we don't recommend releasing applications to end users at this stage is that critical functionality like accessibility support and localization aren't done for desktop yet. Plugin support for desktop platforms is unrelated to those issues, and the only recommendation that we've made about them was not to publish them for pre-alpha platforms (where the APIs were expected to break regularly).

There are still grey areas in the documentation of desktop platforms

Issue reports highlighting those grey areas are welcome 🙂

and unfortunately there are not any native Linux/macOS plugins out there to analyse and clarify those points.

There have been published Linux and macOS plugins since each platform reached alpha, and there have been unpublished-but-public plugins for all desktop platforms in the flutter-desktop-embedding repository since well before then as referenced in the pre-alpha platform documentation. They may or may not cover the specific things you want to know, but again that's an area where issue reports would useful.

I respect your opinion but let me manage my time myself. As I told you before, I have limited time to maintain this project.

My comment wasn't intended to tell you how to manage your time; I was responding specifically to the comment that Linux and alpha weren't sufficient mature to develop plugins for, which is not the case; for desktop, alpha is specifically the milestone where we no longer caution against developing and publishing plugins. Whether you have time or interest to develop this particular plugin for them is of course entirely up to you.

Why don't you share the plugins you know that support web and/or desktop platforms? So, anyone who wants to develop support for those platforms can use them as reference.

https://flutter.dev/desktop#plugin-support

[tanersener]

My comment wasn't intended to tell you how to manage your time; I was responding specifically to the comment that Linux and alpha weren't sufficient mature to develop plugins for, which is not the case; for desktop, alpha is specifically the milestone where we no longer caution against developing and publishing plugins. Whether you have time or interest to develop this particular plugin for them is of course entirely up to you.

Thanks for giving those details about the platform. When I see a library/framework in alpha stage, I assume that the library/platform can still change in terms of API or features. I also expect that version to be unstable. That's why I made that comment. Because alpha versions of the libraries I used before were in this state when I tried to use them.

Anyway, I get that alpha means something more on flutter. So, thanks for explaining that.

I can find macOS, Linux or web plugins on pub.dev too. However, I don't see many desktop or web plugins which has platform specific dependencies. I'm currently using build.gradle on Android and a.podspec file on iOS to download some platform specific libraries. I need to have something similar on other platforms too. Unfortunately, it is not explained here, https://flutter.dev/docs/development/packages-and-plugins/developing-packages#dependencies. I guess using a .podspec file should be possible for macOS. But I have no idea for Linux? For web, most probably it will be npm. But didn't see any plugins using it.

Adding web support has its own issues as well. ffmpeg has to be cross-compiled into something that can be used by the plugin. And I don't have the answer of that. I only know that WebAsm and asm.js are some of the alternatives to be that thing.

[stuartmorgan]

I guess using a .podspec file should be possible for macOS.

Correct; macOS and iOS share the podspec infrastructure.

But I have no idea for Linux?

There is not currently a standardized dependency management solution for Linux plugins; flutter/flutter#32720 would be the issue to follow for that. Specific examples of the libraries you need, and any dependency management systems on Linux that currently vend them, would be interesting data points.

[tanersener]

snap seems to be a good distribution agnostic solution for Linux. I haven't published something with it before but it doesn't look too difficult.

Among all these platforms web is the most difficult one. And, the main problem is not the cross-compilation, it is distributing the binaries.

ffmpeg is subject to software patents. Until now, I distributed those binaries for applications in a format where it was not possible (or too difficult) to use them in an end-user device.

On Android, Google Play distributed the binaries to devices. On iOS, AppStore distributed them. For macOS that can be again AppStore and for Linux, most probably snap will distribute the binaries.

For web, I don't have a format that will allow only developers to use them. If I create ffmpeg.js and upload it to a website, end users will download that version and use it on their devices and I'll become the distributor of the binary. I definitely don't want to do that and create a legal trouble for me.

[YazeedAlKhalaf]

I know you might be busy but can we have a roadmap for adding support for web, and desktop platforms.

The web is in the beta stage
Windows, macOS, Linux are in the alpha stage

For the web, I guess you won't face legal problems if you read below. It says you just need to put some text in the site that shows that the license is LGPLv2.1, you can read below for more info.

License Compliance Checklist
The following is a checklist for LGPL compliance when linking against the FFmpeg libraries. It is not the only way to comply with the license, but we think it is the easiest. There are also a few items that are not really related to LGPL compliance but are good ideas anyway.

Compile FFmpeg without "--enable-gpl" and without "--enable-nonfree".
Use dynamic linking (on windows, this means linking to dlls) for linking with FFmpeg libraries.
Distribute the source code of FFmpeg, no matter if you modified it or not.
Make sure the source code corresponds exactly to the library binaries you are distributing.
Run the command "git diff > changes.diff" in the root directory of the FFmpeg source code to create a file with only the changes.
Explain how you compiled FFmpeg, for example the configure line, in a text file added to the root directory of the source code.
Use tarball or a zip file for distributing the source code.
Host the FFmpeg source code on the same webserver as the binary you are distributing.
Add "This software uses code of <a href=http://ffmpeg.org>FFmpeg</a> licensed under the <a href=http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html>LGPLv2.1</a> and its source can be downloaded <a href=link_to_your_sources>here</a>" to every page in your website where there is a download link to your application.
Mention "This software uses libraries from the FFmpeg project under the LGPLv2.1" in your program "about box".
Mention in your EULA that your program uses FFmpeg under the LGPLv2.1.
If your EULA claims ownership over the code, you have to explicitly mention that you do not own FFmpeg, and where the relevant owners can be found.
Remove any prohibition of reverse engineering from your EULA.
Apply the same changes to all translations of your EULA.
Do not misspell FFmpeg (two capitals F and lowercase "mpeg").
Do not rename FFmpeg dlls to some obfuscated name, but adding a suffix or prefix is fine (renaming "avcodec.dll" to "MyProgDec.dll" is not fine, but to "avcodec-MyProg.dll" is).
Go through all the items again for any LGPL external library you compiled into FFmpeg (for example LAME).
Make sure your program is not using any GPL libraries (notably libx264).

[tanersener]

License and patents are different things. See Patents section of the README.

[EriKWDev]

I see this issue was removed from the roadmap. Does that mean that there is no longer plans on supporting this or that development is stale until dependency management is sorted out for flutter desktop?

[tanersener]

No, I'm working on these platforms but I don't have a release plan yet. It takes time to introduce support for a new platform.

[rgb1380]

@tanersener Thanks for the awesome plug-in and continuing to work on extending it to other platforms. It will be great if web support could be prioritised.

[saviourdog]

@tanersener thanks a lot

[dannycortesv]

Is it possible to make ffmepg runs on mac os with current macOS flutter support?

[YazeedAlKhalaf]

@tanersener Any updates after the Flutter 2.0 release?
Now all platforms are in the stable channel, a kinda stable state though.

[tanersener]

I already completed adding the support for macOS and new Apple architectures natively. But I won't release those changes under flutter_ffmpeg. My plan is to implement them under a new flutter plugin and retire flutter_ffmpeg. I have a long list of reasons to do this. In terms of API, it will be almost the same. So, it will be easy for you to migrate, if you choose to.

The plan is to release that new plugin in the next month. Then I'll focus on Linux and web.

[YazeedAlKhalaf]

I already completed adding the support for macOS and new Apple architectures natively. But I won't release those changes under flutter_ffmpeg. My plan is to implement them under a new flutter plugin and retire flutter_ffmpeg. I have a long list of reasons to do this. In terms of API, it will be almost the same. So, it will be easy for you to migrate, if you choose to.

The plan is to release that new plugin in the next month. Then I'll focus on Linux and web.

Wow, that's really cool, I am so excited. Can you link the GitHub repo so we can contribute to it?
I am really excited 🎉

[tanersener]

Well, I'll implement those changes under ffmpeg-kit. But the development of the flutter plugin is still in early stages, nothing is pushed yet. There will be a folder named flutter where the Flutter plugin will be maintained.

[arbile26]

any updates?

[tanersener]

Flutter plugin of ffmpeg-kit will be released in a few weeks time. It will include macOS support if we don't encounter big issues. That's the only update I have at the moment.

[aoatmon]

@tanersener
what about using https://github.com/ffmpegwasm/ffmpeg.wasm + https://github.com/dart-lang/wasm for all the platforms?

[tanersener]

@aoatmon What do you mean by all platforms?

[aoatmon]

@tanersener
what about using https://github.com/ffmpegwasm/ffmpeg.wasm + https://github.com/dart-lang/wasm for all the platforms?

@aoatmon What do you mean by all platforms?

as android ios macos linux and win can now use wasm
I don't see a real obstacle to have a federated plugin that spins the same wasm for
all mobile desktop and web platforms

[tanersener]

as android ios macos linux and win can now use wasm

I get your point, but we already have working native implementations for android and ios. What will we achieve by using wasm modules instead of native ones on those platforms?

[aoatmon]

as android ios macos linux and win can now use wasm

I get your point, but we already have working native implementations for android and ios. What will we achieve by using wasm modules instead of native ones on those platforms?

consistent behavior I guess and probably the initial effort will repay itself in the long run
but it's your repo so your rules.

so far I'm very happy of how your plugin works, I can only say thank you

[tanersener]

No, it's not about putting rules. I don't have enough time to work on all requests. So, I try to prioritise and spend time on things that are more visible. That's it.

[tanersener]

Hi, we will retire flutter_ffmpeg in the upcoming days and continue with FFmpegKit. FFmpegKit includes a Flutter plugin that improves flutter_ffmpeg in many ways. And the plan is to implement web support there.

We have this issue where we talk about the web support. Would you mind sharing ideas about what you need and expect from the web implementation?

We also have #3 for Linux and #8 for Windows. Btw, macOS is already implemented there.