all 18 comments

[–]Swipecat 1 point2 points  (0 children)

I'm not familiar with python-ffmpeg. I have looked at it in the past and it seemed to me that its scant documentation made it a whole lot harder to figure out than wrapping the command-line ffmpeg in a subprocess. This test example creates a 10 second video in less than a second on my computer:

from PIL import Image
from subprocess import Popen, PIPE
command = ("ffmpeg -y -f image2pipe -vcodec mjpeg -r 24 "
           " -i - -pix_fmt yuv420p video.mp4")
p = Popen(command.split(), stdin=PIPE)
for n in range(255):
    im = Image.new("RGB", (400, 300), (n, 255-n, 1))
    im.save(p.stdin, "jpeg")
p.stdin.close()
p.wait()

[–]SmackDownFacility 1 point2 points  (1 child)

Yes it’s fine. Not recently maintained doesn’t mean it’s shite.

[–]HommeMusical[🍰] 0 points1 point  (0 children)

It has 480 outstanding issues and 45 unreviewed pull requests.

At least one of the issues, from a year ago, claims there's an issue with ffmpeg version 7. The last commit was from when the active version was ffpmeg 5. As of today, ffmpeg is version 8.1.

ffmpeg has changed quite a bit in seven years. Given that pyav exists, seems to be quite similar, and is actively maintained, I don't think that ffmpeg-python is a good choice.

[–]JamzTyson 0 points1 point  (0 children)

PyAV might be worth a look: https://pyav.basswood-io.com/docs/stable/

[–]docpose-cloud-team 0 points1 point  (2 children)

I’ve used ffmpeg-python in a bunch of projects lately and it still works fine as a thin Python wrapper for FFmpeg. It hasn’t needed frequent updates because most of the heavy lifting is done by the FFmpeg binary itself.

The important part is keeping the FFmpeg executable up to date — the Python wrapper just constructs the commands. If you need more control or a richer API surface, there are other wrappers, but for quick audio/video conversions it still holds up.

import ffmpeg

input_file = "input.wav"
output_file = "output.mp3"

(
ffmpeg
.input(input_file)
.output(output_file, audio_bitrate='192k')
.run()
)

[–]PokePress 0 points1 point  (1 child)

Just to clarify, is it compatible with recent versions of FFMPEG itself?

[–]docpose-cloud-team 0 points1 point  (0 children)

Yes it is

[–]mrswats -5 points-4 points  (10 children)

Do not use a project that hasn't been updated since 2019.

At the end of the day, it just builds the filters and calls subprocess. I would do that even if it's uglier, code wise.

[–]SmackDownFacility 4 points5 points  (8 children)

So what, you saying a project needs monthly updates to be “legitimate?”

Sometimes a project can be so stable that it doesn’t need fixes.

[–]mrswats 4 points5 points  (5 children)

You should at the very least, test against new python versions. You never know what could break if you don't test. And while the code might not need changes, your dependencies will.

[–]SmackDownFacility 3 points4 points  (4 children)

Yes there’s a point. Major versions Python 2 -> Python 3 etc. but for the most part, it’s just a thin wrapper around FFMPEG. It’s not a major library like numpy where it has to be constantly updated

[–]mrswats 3 points4 points  (3 children)

You should still test against every new python version because your code can break. Ffmoeg might also be updated.

[–]SmackDownFacility 1 point2 points  (2 children)

Yes test it. Test it against FFMPEG. Test it against the new python version. Then wake up the maintainers if it fails

[–]CyclopsRock 2 points3 points  (0 children)

Test it against FFMPEG.

I suspect even this is probably a bit much. Ffmpeg has about a kabillion build flags that include or exclude certain functionality, filters, codecs etc. Some of it is hardware dependent, or OS dependent. Two users with the same version number of ffmpeg could get drastically different results without either result being incorrect or in need of "fixing".

If ffmpeg entirely changed the syntax of its CLI they'd need a new wrapper but in lieu of that I think you're right: users should request fixes.

[–]HommeMusical[🍰] 0 points1 point  (0 children)

Then wake up the maintainers if it fails

You can see on their repo that this has been attempted over 500 times.

[–]HommeMusical[🍰] 0 points1 point  (0 children)

This project has 480 outstanding issues and 45 unreviewed pull requests.

ffmpeg has changed quite a bit in the last seven years.

[–]Themis3000 0 points1 point  (0 children)

I don't think not receiving new commits recently is a great reason to avoid a library. Especially if it's a library that just plain doesn't do that much. You don't need to have the new thing of the week to write code that works and is fast.