I'm making a python GUI app and using ffmpeg to encode files. I'm bundling ffmpeg with it, so I'm wondering what do I need to make it portable. Would it work with just the ffmpeg binary in my /opt/local/bin folder?
Whatever binaries you distribute with your application need to be compiled for each target platform you want them to run on.
Related
I have archive software that uses ffmpeg on a Solaris server to generate previews during the archive process. I have installed ffmpeg on the Solaris server following the steps outlined here
It appears as though the package installs successfully but if I run 'ffmpeg' as root I receive '-bash: ffmpeg: command not found'. From what I understand, running this command is what needs to work for the archive software to be able to use ffmpeg. From a bit of research it looks like I either have to move the ffmpeg install location to somewhere else or define some path that points to the ffmpeg software. My Solaris knowledge is limited so I am not sure how to do either of those things. Could someone describe how to define the path or move the installed package to the correct location?
Thank you
So, after poking around a bit, I discovered that ffmpeg may have the ability to load tracker files (like *.mod, *.xm *.it *s3m et cetera) via the power of libopenmpt.
The question is, how do I do this if it's possible?
Look for a ffmpeg binary that has support for libopenmpt, or the older but buggier libmodplug; refer to the FFmpeg Download page for links. Otherwise, you'll have to compile it.
Get the ffmpeg source code.
Install libopenmpt.
Install any other needed dependencies.
Compile ffmpeg ensuring you include --enable-libopenmpt when you run configure.
You did not include any information about your system, so you'll have to adapt one of the guides at FFmpeg Wiki: Compile.
While compiling ffmpeg it's showing Unknown encoder libfdk_aac error.
Can anyone explain how I can install libfdk_aac for my FFMPEG?
I am using centos 6.
libfdk_aac is considered non-free and therefore non-redistributable, so you should find no builds with support for this encoder. Therefore, you must compile.
The FFmpeg Wiki has a compile guide with step-by-step instructions for CentOS. The resulting ffmpeg binary will support libfdk_aac:
FFmpeg Wiki: Compile FFmpeg on CentOS
Note that this guide performs a "local installation" into the ~/bin directory of the user following the guide: this is to avoid conflicts with the package management system, system files, and repository packages. Also, it allows a non-superuser to compile, such as on a shared server (assuming the build dependencies, like make, are available). This works fine for most users, but depending on your needs you may have to move the binary somewhere else in your PATH environment variable.
Alternatively, you could just use a different AAC encoder. Feed it enough bits and you'll do fine.
Generally, "link-only" answers are discouraged, but I'm going to make an exception in this case. I am hesitant to copy and paste the content from the link because of the size of the guide and the likely chance that the answer will become outdated as the guide is updated (such as what happens to the many rotting copycat compile guides).
I'm trying to add support for Ogg Vorbis in my project (C++, VS 2010). I had no problem compiling LibOgg + LibVorbis to produce a static library.
My procedure is this:
LibOgg
Download LibOgg
Build LibOgg with dynamic solution (Release)
Get a libogg.lib export and a libogg.dll in /Release folder
LibVorbis
Download LibVorbis
Set appropriate include + library folders for LibOgg
Build LibVorbis with dynamic solution (Release)
Get a libvorbis.lib and libvorbisfile.lib exports and libvorbis.dll and libvorbisfile.dll in /Release folder
My program
Set appropriate include + library folders for Libogg + LibVorbis .lib exports
Place .dll in working directory
The build succeeds but unlike the static build (which works), the dynamic build just crashes in the first ov_open call (which opens some .ogg file). I built lots of libraries (GLEW, SQlite, etc.) yet this one gives me the nuts.
Never mind, i solve this.
It seems OggVorbis is touchy when it comes to Windows and use of ov_open due to some linking issues with stdio.h and fopen.
Documentation says it clearly:
WARNING for Windows developers: Do not use ov_open() in Windows
applications; Windows linking places restrictions on passing FILE *
handles successfully, and ov_open() runs afoul of these restrictions
[a]. See the ov_open_callbacks() page for details on using
ov_open_callbacks() instead.
Although it is recommended by docs to use callbacks, i found ov_fopen to be reliable which works for both static and dynamic builds with the OggVorbis; the dynamic build will crash your program if you use ov_open on Windows.
Going to update this answer after i test it against Linux and OSX to verify ov_fopen as a safe, all around solution.
UPDATE
As said, i tested the use of ov_fopen on Windows 7, Linux (Lubuntu), OSX (10.8.2) and Android (KitKat 4.4.4) and i found out that works reliably. So, for those allergic to callbacks (like me), ov_fopen proved reliably.
I need to build ffmpeg for Mac for converting MOV to FLV in a Java application. I made and installed LAME and then FFMPEG, but I'm confused as to what file I should grab to include with the Java application. What is the binary file? The previous version that I grabbed from the source of ffmpegX was 10mb in size, but the file that's in my /usr/local/bin is only 0.1mb. Is that the right file, or what do I need to include?
I'm not too savvy with anything that needs to be typed into Terminal, so excuse the lack of technical jargon!
Short answer: that file in /usr/local/bin is either the real binary or a soft link to the real binary. If you run ls -l /usr/local/bin any links will be displayed with an arrow to their target location. But pszilard is probably right, that file might be the actual binary, which was dynamically linked to library code.
Long answer: If you compiled from source, then you ran the following three commands
./configure
make
make install
The first one creates a configuration file called config.mak. Near the top of that file, you'll see a lines similar to the following:
prefix=/usr/local
LIBDIR=$(DESTDIR)${prefix}/lib
SHLIBDIR=$(DESTDIR)${prefix}/lib
INCDIR=$(DESTDIR)${prefix}/include
BINDIR=$(DESTDIR)${prefix}/bin
DESTDIR is optional; it's irrelevant unless you ran make install with an additional argument. BINDIR is the actual install location. On my system (snow leopard) that was /usr/local/bin/.
If you're still having trouble, just don't install the build. If you run
make clean
make
The binary will be in your build folder.
Don't use MacPorts or Fink. You'll be happier in the long run if you compile from source yourself. If you insist on using a package manager, try Homebrew <Link>.
I'm not a Mac expert by far, but I've a few tips. If you build the lib with dynamic linkage and the the other one was statically linked that might explain the size difference.
As for the location, what did you use? MacPorts, Fink, or source? If you built from source depends what you used :) MacPorts and Fink have their specific location for binaries (I don't remember anymore, but the documentation should have the info, otherwise the big G has it ;)