Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comparison with ffmpeg-cli-wrapper #14

Open
NebelNidas opened this issue Jun 2, 2023 · 1 comment
Open

Comparison with ffmpeg-cli-wrapper #14

NebelNidas opened this issue Jun 2, 2023 · 1 comment

Comments

@NebelNidas
Copy link

I'm looking for a library that provides Java bindings for FFmpeg. During my research I stumbled upon both ffmpeg-cli-wrapper and this repo here, ffmpeg4j. From a quick glance it looks like both projects share the same goals, however ffmpeg-cli-wrapper seems to be the older and more established option compared to ffmpeg4j. Which leaves me with two questions:

  1. Are there any major differences between the two libraries?
  2. If no, why was ffmpeg4j created?

Would be nice if this could be mentioned in the README as well.

@Manevolent
Copy link
Owner

Manevolent commented Jun 30, 2023

Are there any major differences between the two libraries?
FFmpeg4j solves a specific use case where you don't want to/can't run a sidecar executable (i.e. ffmpeg.exe) to delegate processing. While the ffmpeg-cli-wrapper project is certainly a good fit for a wide variety of use cases, in my specific scenario I needed a project that could move data efficiently. I found piping byte-streams from another executable via stdin/stdout to be inefficient. FFmpeg4j works directly inside the JRE using JavaCPP's JNI bindings, so real-time tasks like livestreaming are far more performant; this would be my big sales pitch. Also useful is having programmatic access to enumerate the individual streams, as well as seeking being supported now.

For a more real world example, I've used FFmpeg4j to do transcoding (something that project does phenomenally I assume), but I'm able to directly hand a Java HTTP response stream to FFmpeg. I can avoid hitting the filesystem at all, which is something I really needed. Most CLI wrappers are going to want a file input, or pipe them a media file via stdin, both of which have throughput issues in my testing.

Without really doing a ton of research into the CLI wrapper, I would say an advantage FFmpeg4j has is that you have a very low-level API into FFmpeg objects (streams, frames, codecs, etc.) since it's based around JavaCPP, and you have the memory management handled for you as well (i.e. object/resource cleanup). So, you have a lot more control if you're doing something other than file-to-file transcoding or something.

Due to ffmpeg-cli-wrapper's sheer visibility and maintenance, it's going to be a better choice for production for any use case that FFmpeg4j isn't specifically targeting. I don't have a ton of focus on this project; you'll see my response time isn't exactly dependable for big production projects.

I'm going to leave this ticket open so other people can see my thoughts on this until I can draw up a better comparison on the README.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants