B4J Library [B4j] Jave2 FFMPeg Library

After using FFMpeg from the command line, I came across Jave2 (Java Audio Video Encoder) a java wrapper based on FFMpeg. Useful to integrate FFMpeg into your app without having to use jShell. The library jars are quite large, so if you only want to use it for the odd conversion it might be better to use the Shell option. With the library, users of your app won't have to install FFMpeg on their machines.

There are 2 b4xlibs attached and a test project for each (you will have to change at least the source and target filenames to use the test projects). if you want to get real-time messages (progress information) you need to use the Threaded version of the library.

There are some examples on the jave2 github page, but not many. If you don't know FFMpeg, you can search the internet for the examples you need. It should be easy enough to implement them with the library.

Setup
  • Download jave-core and whichever nativebin file(s) you wish to use from their Maven Repository into your B4j additional libraries folder.
  • Download slf4j-api-2.0.0.jar and slf4j-nop-2.0.0.jar from the slf4j Maven Repository into your B4j additional libraries folder if you don't already have them.

External Dependencies
  • Non Thread version - None
  • Threaded version - Threading
Comments
Use the threaded version if you are going to convert large files, otherwise the Gui will be blocked.​
The test apps use nativebin-win64. You will need to change that in the #AdditionalJar directive if you want to use something different.​

Update
FFMpeg-Threaded-b4xlib v 0.12 - 25 Aug 2022

  • Listener is created automatically if needed. Changed Initialization parameters
  • Added Complete event that can be used with Wait For to queue conversions for the threaded calls
  • Test app also updated.

I hope you find it useful.
 

Attachments

  • FFMpeg-b4xlib.b4xlib
    8.5 KB · Views: 260
  • FFMpeg-Test.zip
    2.5 KB · Views: 274
  • FFMpeg-Threaded-b4xlib.b4xlib
    9 KB · Views: 289
  • FFMpeg-Threaded-Test.zip
    2.7 KB · Views: 262
Last edited:

stevel05

Expert
Licensed User
Longtime User
Update
FFMpeg-Threaded-b4xlib v 0.12 - 25 Aug 2022

  • Listener is created automatically if needed. Changed Initialization parameters
  • Added Complete event that can be used with Wait For to queue conversions
  • Test app also updated.
 
Last edited:

DonManfred

Expert
Licensed User
Longtime User

stevel05

Expert
Licensed User
Longtime User
Hmm, If only ;)
 

stevel05

Expert
Licensed User
Longtime User
Only what's available on the Jave2 Github page. I don't know FFMpeg that well, so don't know if there is anything missing.
 

xulihang

Active Member
Licensed User
Longtime User
This library uses GPL3.0. Maybe JavaCV is a better choice for a close-sourced app as its license is Apache 2.0.
 

peacemaker

Expert
Licensed User
Longtime User
Is any noticeable speed difference in usage comparing to SHELL calling CLI ffmpeg ?
I use it for grabbing IP-camera RTSP-stream, and speed is about 1 frame per second from the FullHD stream in a local Ethernet 100Mbps network (camera ping is 5...10 ms).
Any better result possible with the wrapped methods ?
 

Magma

Expert
Licensed User
Longtime User
Is any noticeable speed difference in usage comparing to SHELL calling CLI ffmpeg ?
I use it for grabbing IP-camera RTSP-stream, and speed is about 1 frame per second from the FullHD stream in a local Ethernet 100Mbps network (camera ping is 5...10 ms).
Any better result possible with the wrapped methods ?
Do you mean you jshell ffmpeg exe file and capture to jpeg file ... all this process taking 1 second... hmmm... did you ve change the compression... I am pretty sure you can capture about 10 frames / sec... somehow... (at least)

Well I am sure there is an ffmpeg capture wrapper... but I can't remember where I ve seen it last time...

Sorry for asking... what's the way you are using...

command line:
ffmpeg url_of_camera -settings
-settings can be anything...
Or you are showing at a form and then capture it ????

---Also... we can talk private because this is a different thread... not mixxed with our questions for different things
 

JackKirk

Well-Known Member
Licensed User
Longtime User
I have been launching ffmpeg via the B4J/shell route for about 4 years without incident.

One advantage I see to this approach is that it is a trivial exercise to update ffmpeg when necessary.

What is the story re this library and ffmpeg updates?
 

stevel05

Expert
Licensed User
Longtime User
What is the story re this library and ffmpeg updates?
I can only check on the projects Github page. it looks like it's a couple of releases behind but updated regularly. If you want the latest FFMPeg functionality, continue using the shell method.
 

JackKirk

Well-Known Member
Licensed User
Longtime User
If you want the latest FFMPeg functionality, continue using the shell method.
I don't necessarily want the latest functionality but what I do want is ease of update when I do want some new feature.

Using the library approach, if I found I needed some new feature I would have to:
  • Ensure that the github project has been updated appropriately.
  • Ensure you update the library.
  • Recompile my project.
3 steps - 2 of which are out of my control and most likely involve a lag.

Using the shell approach all I have to do is copy the new ffmpeg.exe to the appropriate location.

This is not to knock your effort but I am involved in a big project that has ffmpeg as a significant component - long term maintainability is a serious concern.
 

stevel05

Expert
Licensed User
Longtime User
I agree, this is a convenience library. I only use it for basic Audio / video conversion so would not miss any new features unless a new codec takes the world by storm.

To address point 2 from a general maintenance perspective, 99% of my libraries are now B4xlibs, the source code is available in the library download (just unzip it). If I was unavailable to do it, and you needed to add a new method, it would take you 10 mins, unless it was a complex change to the way the library worked which is unlikely.

I am involved in a big project that has ffmpeg as a significant component - long term maintainability is a serious concern.

Then from a security perspective, you need to question whether you should be using free open source libraries in your project at all.

FFMpeg is a free open source library. It is unlikely, but it could stop being updated tomorrow. If it really is that big a project and / or your business depends on it, then you should have contingency plans in place, such as having the skills to be able to maintain or update these libraries from their source code, or being able to pay someone to do so.
 

JackKirk

Well-Known Member
Licensed User
Longtime User
FFMpeg is a free open source library. It is unlikely, but it could stop being updated tomorrow. If it really is that big a project and / or your business depends on it, then you should have contingency plans in place, such as having the skills to be able to maintain or update these libraries from their source code, or being able to pay someone to do so.
I understand and spent a fair bit of time researching and agonizing before I committed to ffmpeg - but I have found nothing comparable that was so easy to plug in.

The project is big and getting bigger but I am not dependent on it - I'm 75 in a week's time.

As regards contingency plans I have a much bigger concern about what would happen to the 10,000 odd hours I have put into it if Erel had a misadventure - I worry about one-man bands and really don't like the idea of him living within spitting distance of the Golan Heights.

I have recently signed a contract to do the first install - these are big installs involving lots of networked high-end security cameras - with the prospect of a great many more if this one works financially. My first order of business if and when it succeeds is to man up.
 

stevel05

Expert
Licensed User
Longtime User
It sounds like the "if it ain't broke don't fix it" maxim applies here. Just before release is not a time to be making changes to the core of a working and tested system.

I release these libraries because I find them useful and think that others might. Although I do my best to test them, they come with no guarantees it is up to each developer to test them to destruction before using them in an application that is destined for distribution, not least because they may be using them in a way they weren't initially intended.

Good luck with the install :)
 
Top