4 ms·

I would gladly donate to anyone that wants to statically bind this for use with Go. I really would love to see the power of FFmpeg open to more apps. I've used

I would gladly donate to anyone that wants to statically bind this for use with Go. I really would love to see the power of FFmpeg open to more apps. I've used FFmpeg libs dynamically linked, but it requires FFmpeg be installed on the system.

xmichael99 9y ago
I would gladly donate to anyone that wants to statically bind this for use with c# with mono multiplatform support. I really would love to see the power of FFmpeg open to more apps. I've used FFmpeg libs dynamically linked, but it requires FFmpeg be installed on the system.
- etaioinshrdlu 9y ago
  Indeed, this would be great. This actually came up for me a couple days ago, and my ham-fisted solution was to bundle ffmpeg.exe and ffplay.exe in the DLL and extract when running :) It solved the problem but is so gross!
jallmann 9y ago
I looked at some FFmpeg-Go bindings recently. Concluded that it was less effort to write exactly the functionality that's needed in C and expose that to Go, rather than fix up an all-encompassing API. More here: https://github.com/livepeer/lpms/issues/24 https://github.com/livepeer/lpms/issues/24
innagadadavida 9y ago
IMO better to fork/exec ffmpeg to avoid memory leaks and security issues. The fork/exec takes a few microseconds and works well (you can even pipe it data). Of course, if the command line options doesn’t do what you want, that’s a different issue.
- blt 9y ago
  How to deal with efficiency issues from the huge amount of data being piped? Shared memory area and send pointers over the pipe?
  - Something1234 9y ago
    Is this really a problem with pipes. I found that I can easily push 8-9 GIB/s over a standard pipe on my 4 year old desktop yes | pv > /dev/null
mattip 9y ago
Note any such code would be covered by the GPL. This is why so many people use the cli - by using pipes or sockets your code ( as far as I can determine, you should get real legal advice) can be released under a different license

xmichael99 9y ago

I would gladly donate to anyone that wants to statically bind this for use with c# with mono multiplatform support. I really would love to see the power of FFmpeg open to more apps. I've used FFmpeg libs dynamically linked, but it requires FFmpeg be installed on the system.

etaioinshrdlu 9y ago
Indeed, this would be great. This actually came up for me a couple days ago, and my ham-fisted solution was to bundle ffmpeg.exe and ffplay.exe in the DLL and extract when running :) It solved the problem but is so gross!

jallmann 9y ago

I looked at some FFmpeg-Go bindings recently. Concluded that it was less effort to write exactly the functionality that's needed in C and expose that to Go, rather than fix up an all-encompassing API. More here: https://github.com/livepeer/lpms/issues/24 https://github.com/livepeer/lpms/issues/24

innagadadavida 9y ago

IMO better to fork/exec ffmpeg to avoid memory leaks and security issues. The fork/exec takes a few microseconds and works well (you can even pipe it data). Of course, if the command line options doesn’t do what you want, that’s a different issue.

blt 9y ago
How to deal with efficiency issues from the huge amount of data being piped? Shared memory area and send pointers over the pipe?
- Something1234 9y ago
  Is this really a problem with pipes. I found that I can easily push 8-9 GIB/s over a standard pipe on my 4 year old desktop yes | pv > /dev/null

mattip 9y ago

Note any such code would be covered by the GPL. This is why so many people use the cli - by using pipes or sockets your code ( as far as I can determine, you should get real legal advice) can be released under a different license