Separate Render core code from FFMpeg

[Azramis]

To begin, I would like to thanks you for this incredible package ! Usage is simple and efficient 👌

Is your feature request related to a problem? Please describe.
As I mention it in another issue, I'm facing a problem when I want to use a different implementation of FFMpeg. Render depends of ffmpeg_kit_flutter_https_gpl which have only a few external library.

Describe the solution you'd like
I want to be able to write a custom MotionFormat that use libvpx external library (from ffmpeg_kit_flutter_video) for exemple.

This solution that seems the most obvious to me, is the separation of the code in two packages :

• render_core, which provides abstractions and process of bitmap datas extraction. Datas will be interpreted/transformed by the new render package, or by custom implementations
• render, which provides the current implementations, as the package is today

Also, it might be a good way to implements a web dedicated render package (i.e. render_web), based on render_core with no ffmpeg_kit_flutter deps.

Maybe there is a simplier and better solution (would be great !)

Describe alternatives you've considered
Fork the project an do it for myself.

I would be happy to work on this and open a PR, but it should be better to discuss about solutions before

[polarby]

Hi @Azramis,
Thanks for your input!
Generally, this seems a great idea, where render_core could become a platform for others to build ontop. So let me get this straight:

The render_core package (basic functions, without the processing, therefore eliminating imports of ffmpeg) is the centered main package.
And then the Packages that depend on render_core with the platform (or custom) ffmpeg imports that then take the data from render_coreand "only" process it.

There would be two "user-friendly" packages:

• render: the default package -ffmpeg_kit_flutter for mobile
• render_web: for people who want web, with ffmpeg_wasm

For the forkers:

• render_YourCustomName: for people who for example want to adjust the ffmpeg_kit_flutter plugin (such as ffmpeg_kit_flutter_video) and can copy/fork the code from render (...and eg. extend functions or MotionFormats)

Conclusion:

I think this separation would clear things up a bit, but it would not change the way it is handled right now anyway, right?
If People want a custom flutter import, they would still have to fork a package, just this time a bit smaller (render, without the code of render_core).
I agree, that this separation, might make extending the endpoint easier.
Don't get me wrong, I would love a simplification, but it might involve too much work (for you) and not too much of a gain?!

An extending idea:

If, on the other hand, we additionally add the packages like below, it might not even be necessary anymore to fork anything if there are ffmpeg import issues. (And would clear up issues like #18 )

• render_ffmpeg_min
• render_ffmpeg_min-gpl
• render_ffmpeg_[other ffmpeg_kit_flutter plugins]
  ....

Here for reference the different packages offered by flutter_ffmpeg

PS. Let me know if understood your idea correctly :) And please correct me if I am wrong.

[Azramis]

Thank you for the quick feedback !

You get the biggest idea behind my words ;)
In my opinion, render_core should only be responsible of extracting bitmap datas, one-shot (image) or streamed (motion), and delegate the processing of these datas to a... Delegate 😁 Therefore, it will be possible for anyone to "custom" process the datas, and to make what they want with it.

Possibilities become multiple :

• Independance from FFMpeg
• Stream frames through a network
• Multi-threading

BTW, it should be necessary to build the new render package as it will cover the most retro-compatibility from the current. Lesser breaking changes, better the migration is !

Offer "ready-to-use" packages would be great, and the two you listed are a minima.

Forkers will probably be happy, but just like in my case, my app will only depends on the core and will implements only what I need. So I don't have to fork an entire project, and depends on a local package.
Main idea = Flexibility at most

Main changes

• Remove ffmpeg_kit_flutter_* dependency
• Don't use dart:io anymore in render_core, as we cant use it from Flutter Web
• Think how to implements a Delegate in simpliest way (from code writing, to injection)

I'll be really enthusiast to be involved in these devs, and I'll try to take the time for its. My current work project depends of your package, and better flexibility in it means more possibilities for me 😁

What's next

I've forked the project and began to extract code.
A question remains: How do you imagine packages separation ?

From my experience, I worked with melos it allows to work with multi libraries on a mono repo. It manages versioning through conventional commits and local dependencies. Coupled with fvm it's a game killer in my opinion.

Despite this, it's important for me to have your opinion, as you are the creator of render

Extending Idea

I'm not for it, as it would complicate things.
It might be simplier to provide quickly, but I think maintenance will be nightmare when you want to upgrade dependencies versions...
Also, I prefer to have more flexibility, so... 🙃

[polarby]

Thanks for clearing things up and explaining.
I am quite busy, so I can't help you to write/rearrange the code too much. It would be great if you could help us improve this plugin with your idea.

Execution:

• Move main parts of the code to a new repository render_core
• Link the current repo render to the render_core
• Write documentation for extending render_core and which package to use (eg. for later render_web)

I have added you to the repository as a collaborator. You have my go :)

PS. If you need special permissions please let me know. ALSO: i have already created a plane repository for render_core, feel free to use this :)

[Azramis]

Sorry for the late feedback.

I'm currently working on it, and testing on a mono-repo. When I'll be satisfied with a first version, I'll push it to the render_core repo you have created.

I'll try to write documentation at my best, but let be honest, that's not where I'll be the best 😂

[Azramis]

Quick update.

I'm really busy for now, and I couldnt work on that since my last message. 🤦
And I don't know when I'll have free time to work on it...