search

Manevolent / ffmpeg4j

A Java OOP FFmpeg wrapper around the JavaCPP FFmpeg native library bindings
Apache License 2.0
105 stars 16 forks source link

Comparison with ffmpeg-cli-wrapper #14

Open NebelNidas opened 1 year ago

NebelNidas commented 1 year ago

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 commented 1 year ago

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.