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 4 days ago | parent | next [-]

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.

▲

kaladin-jasnah 3 days ago | parent | next [-]

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....

▲

f1shy 4 days ago | parent | prev [-]

It could even make sense in C. In some circumstances, I wouldn’t feel bad for cutting that corner.

	▲	1718627440 4 days ago \| parent [-]
		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.

▲

ansk 4 days ago | parent | prev | next [-]

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

▲

javier2 4 days ago | parent | prev [-]

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 4 days ago \| parent [-]
		Also because you can apply stricter sandboxing/jail/containerization to the process.