4 ms·

FFMpeg does have an API. It ships a few libraries (libavcodec, libavformat, and others) which expose a C api that is used in the ffmpeg command line tool. They

• zahlman 1y ago
  Don't know how I overlooked that, thanks. Maybe because the one Python wrapper I know about is generating command lines and making subprocess calls.
  • Wowfunhappy 1y ago
    They're relatively low level APIs. Great if you're a C developer, but for most things you'd do in python just calling the command line probably does make more sense.
    • f1shy 1y ago
      It could even make sense in C. In some circumstances, I wouldn’t feel bad for cutting that corner.
      • 1718627440 1y ago
        Yes, that's what I did some time ago. I already want concurrency and isolation, so why not let the OS do that. Also I don't need to manage resources, when ffmpeg already does that.
    • kaladin-jasnah 1y ago
      As someone that used these APIs in C, they were not very well-documented nor intuitive, and oftentimes segfaulted when you messed up, instead of returning errors—I suppose the validation checks sacrifice performance for correctness, which is undesirable. Either way, dealing with this is not fun. Such is the life of a C developer, I suppose....
  • javier2 1y ago
    If you are processing user data, the subprocess approach makes it easier to handle bogus or corrupt data. If something is off, you can just kill the subprocess. If something is wrong with the linked C api, it can be harder to handle predictably.
    • astrange 1y ago
      Also because you can apply stricter sandboxing/jail/containerization to the process.
  • ansk 1y ago
    For future reference, if you want proper python bindings for ffmpeg* you should use pyav. * To be more precise, these are bindings for the libav* libraries that underlie ffmpeg