I am trying to get a live streaming device to work on a raspberry pi. I am running minibian. I roughly follow this guide without the cross compiling.
My problem is probably with the compilation of ffmpeg. I downloaded and compiled both x265 and fdk-aac and compiled them. Next I have to compile ffmpeg, which is in the same folder as the other ones, but the compiler can't find any of the dependencies. x265 also cannot be found using pkg-config, which is the error it produces when I try to run ./configure.
I directly cloned everything into one folder, so that in a folder called ffmpeg_files there are three other folders: ffmpeg, fdk-aac and x265. How do I properly include these dependencies so I can enable them when I compile ffmpeg?
Thank you!
Okay, so this is not really an answer to this question.
After a long time of trial and error and a lot of help by the great user Mulvya I decided not to use Minibian, but Raspbian Stretch Lite. There, everything worked very smoothly. Just remember to run sudo ldconfig after installing the codec libraries like x264/x265 or fdk-aac.
Thanks everybody for your help!
I was stuck getting the same error, and this solution worked for me:
First check if pkg-config can find x265:
$ pkg-config --modversion x265
Package x265 was not found in the pkg-config search path.
Perhaps you should add the directory containing x265.pc to the PKG_CONFIG_PATH environment variable:
No package 'x265' found.
$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
$ pkg-config --modversion x265
0.0
Very much an amateur here, with perhaps even less grasp on the workings of stackoverflow than software compilation, but I hope some positive feedback might help someone else, just as Mulyva has helped me.
After trying and failing to compile ffmpeg on Ubuntu 17.10 (and 16.04 within a virtual machine) with the same error message as the OP and countless others. Compiling x265 rather than using the version in the Ubuntu repos, and using Mulyva's advice in the later chat - "Try with ./configure --enable-static --enable-nonfree --enable-gpl --enable-libx265 --extra-libs=-lm --extra-libs=-lstdc++ --enable-libfdk_aac --extra-libs=-lm --extra-libs=-lstdc++" - has it working for me. Thank you!
Apologies if posting here is embarrasingly out of place...
Related
It installed about 70% of the dependencies it needed to get ffmpegs going, but it got stuck at installing 'doxygen'.
This is the error I got:
==> Installing dependencies for ffmpeg: doxygen, little-cms2, openjpeg, opus, rust, libgit2, cargo-c, rav1e, flac, libsndfile, libsamplerate, rubberband, sdl2, swig, llvm, snappy, speex, srt, leptonica, libb2, lz4, libarchive, tesseract, theora, x264, x265, xvid, docbook, boost, source-highlight, asciidoc, docbook-xsl, libyaml, ruby, asciidoctor, gnu-getopt, xmlto, libsodium, zeromq and zimg
==> Installing ffmpeg dependency: doxygen
==> cmake ..
==> make
Last 15 lines from /Users/macbook/Library/Logs/Homebrew/doxygen/02.make:
In file included from /tmp/doxygen-20220723-61533-5m5mdv/doxygen-1.9.4/src/outputlist.h:25:
/tmp/doxygen-20220723-61533-5m5mdv/doxygen-1.9.4/src/searchindex.h:29:10: fatal error: 'variant' file not found
#include <variant>
^~~~~~~~~
1 error generated.
make[2]: *** [src/CMakeFiles/doxymain.dir/__/generated_src/code.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/doxymain.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 46%] Linking CXX static library ../lib/libvhdlparser.a
cd /tmp/doxygen-20220723-61533-5m5mdv/doxygen-1.9.4/build/vhdlparser && /usr/local/Cellar/cmake/3.23.2/bin/cmake -P CMakeFiles/vhdlparser.dir/cmake_clean_target.cmake
cd /tmp/doxygen-20220723-61533-5m5mdv/doxygen-1.9.4/build/vhdlparser && /usr/local/Cellar/cmake/3.23.2/bin/cmake -E cmake_link_script CMakeFiles/vhdlparser.dir/link.txt --verbose=1
/usr/bin/ar qc ../lib/libvhdlparser.a CMakeFiles/vhdlparser.dir/CharStream.cc.o CMakeFiles/vhdlparser.dir/ParseException.cc.o CMakeFiles/vhdlparser.dir/Token.cc.o CMakeFiles/vhdlparser.dir/TokenMgrError.cc.o CMakeFiles/vhdlparser.dir/__/generated_src/VhdlParser_adj.cc.o CMakeFiles/vhdlparser.dir/VhdlParserTokenManager.cc.o
/usr/bin/ranlib ../lib/libvhdlparser.a
[ 46%] Built target vhdlparser
make: *** [all] Error 2
Do not report this issue to Homebrew/brew or Homebrew/core!
Error: You are using macOS 10.12.
We (and Apple) do not provide support for this old version.
You will encounter build failures with some formulae.
Please create pull requests instead of asking for help on Homebrew's GitHub,
Twitter or any other official channels. You are responsible for resolving
any issues you experience while you are running this
old version.
Can someone please help me am not sure what it is, that I am supposed to do.
Looks like we're in the same boat. Fighting the "good fight", as it were. We should probably both just bail to linux or even windows, because god knows they are going to keep making this hard for us....
However, probably like yourself, a combination of inertia and "good reasons" keeps us staying the course ;)
Basically, the issue is described correctly by the others here (lack of c++ 17 support) and in my case (and likely yours as well) is because gcc is a symlink to clang (9.0 if you are using the latest version compatible with our os)
Telling brew to use real gcc (I assume you have compiled it already, and if not - gcc 11.3.0 is a dependency for ffmpeg anyhow, so go ahead and build it; brew install gcc) can be done like this :
HOMEBREW_CC=gcc-11 HOMEBREW_CXX=g++-11 brew install doxygen
However, the above didn't work for me because - although it solved the c++ 17 issue, it exposed another problem :(
It seems that for some reason the minimum macos version number is messed up (I think because the sdk headers for 10.13 are installed with the latest version of xcode compatible with our os) and so the compilation fails. Although there is almost certainly a better/cleaner way to deal with this issue, I solved it by manually compiling and installing doxygen after editing the code.
In the doxygen/filesystem/filesystem.hpp file around line 4491 you need to change the line
#if __MAC_OS_X_VERSION_MIN_REQUIRED < 101300
to
#if __MAC_OS_X_VERSION_MIN_REQUIRED < 111400
Then compile doxygen (extract the source from the brew cache), cd to the cmake folder then run
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/doxygen/1.9.4 -DCMAKE_INSTALL_LIBDIR=lib -DCMAKE_BUILD_TYPE=Release -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DBUILD_TESTING=OFF -DCMAKE_C_COMPILER=gcc-11 -DCMAKE_CXX_COMPILER=g++-11
make
make install
brew link doxygen
Then continue the brew install ffmpeg. I had trouble with nettle as well, and needed to compile and install that one manually too because the version of libcrypto packaged with macos (libressl) is incompatible. I had to do the steps shown in "brew info openssl#1.1" in order to make sure the compiler used the openssl libcrypto that IS compatible and I couldn't figure out how to make brew do this for me.
Fun fun fun. I am not all that hopeful that the rest of the compilation will go without issue, but it is chugging away again now. I get the distinct impression that this is SO not worth the hassle/trouble.
Good luck!
** EDIT **
I'm still slogging through it, and it is taking a LONG time. But as I encounter more issues I will try and detail them here with the hope that each issue I encounter is reasonably easy to overcome.
llvm failed to compile with lots of missing header errors. Directing brew to use gcc-11 like i did with doxygen worked to compile it further (27%) but still failed (it looks like because it is calling clang specific options as a result of the brew cmake config passed to it... i'm still working on this one...)
Conclusion - I gave up. It isn't worth the time in my view.
Instead I installed macports and used "sudo port install ffmpeg-upstream" to install ffmpeg-5. Unless you have some dying need to compile yourself, I recommend you do this as well.
I've spent quite some time to get around this issue as well and I ended up with another solution. I merely edited the formula to suit my needs :
brew edit doxygen
Once there, spot the "def install" block then edit the file so that it looks like this :
fails_with :clang
def install
inreplace "CMakeLists.txt", "MACOS_VERSION_MIN 10.14", "MACOS_VERSION_MIN 10.11"
Save, exit.
In short, just add the "fails_with" line and the "inreplace" line. The first one causes brew to not use clang (so you need to have a gcc copy somewhere). This is to solve the C++17 issue. The second one patches the CMakeLists.txt file to allows cmake to do its magic. Once done, "brew install doxygen" should succeed.
I'm trying to compile FFMPEG with x265 on Win10. I am using the latest full MinGW build from xhmikosr found at:
http://xhmikosr.1f0.de/tools/msys/
FFMEPG without x265 compiles without problems and compiling x265 standalone works without problems too.
However when i --enable-libx265 in ffmpeg i get the following error:
ERROR: x265 not found using pkg-config
and this from the config.log:
require_pkg_config libx265 x265 x265.h x265_api_get
check_pkg_config libx265 x265 x265.h x265_api_get
test_pkg_config libx265 x265 x265.h x265_api_get
false --exists --print-errors x265
ERROR: x265 not found using pkg-config
my config paths seem to be all set correct.
$ echo $PKG_CONFIG_PATH
C:\MYSYS\local\x86_64-w64-mingw32\lib\pkgconfig
and when i look for the libraries x265 is there:
$ pkg-config --list-all
...
x265 x265 - H.265/HEVC video encoder
...
and here the debug log:
$ pkg-config --debug
...
File 'x265.pc' appears to be a .pc file
Will find package 'x265' in file 'C:/MYSYS/local/x86_64-w64-mingw32/lib/pkgconfig\x265.pc'
...
Why does pkg-config still not find the x265 libraries when i try to compile?
After much trial and error, I believe I have found a solution and the root cause under Ubuntu 16.04. This solution may work for other variants of Ubuntu as well.
If you run into the Package Config error described in this thread, try installing the default (repository based) libraries first, and then install your custom version with your ffmpeg build script.
Run these commands as needed prior to running your custom script to compile ffmpeg and your dependent libraries (e.g. x265) from source:
apt install -y libx265-dev
If another library fails, try the same technique and then run your script again to see if it works. For example, some people report compiling ffmpeg from source complains about gnutls. The solution for Ubuntu 16.04 is to first install it via apt and then run your script.
apt install -y gnutls-dev
If you're hung up at compiling the x264 libraries (for H.264 support), simply run this before running your script:
apt install -y libx264-dev
As long as your new script overwrites the old files and does not purge them, this method will work.
Background/History
The source of the problem dates back to at least 2017, and despite numerous claims it does not appear to have actually been fixed. One can find references in various forums and websites of frustrated users unable to get their compile to work correctly regardless of the version of the ffmpeg build, such as here.
It's a difficult problem to solve partly because the VLC Developer instructions for installing x265 library support are broken. Furthermore, the archive of information explaining this problem and how to solve it is no longer available, due to BitBucket's decision to sunset Mercurial support earlier this year. Most archived forum posts explaining the problem and how to solve it are gone. There are a few clues still to be found on GitHub, but they are incomplete snippets of information on the topic; none offer a complete perspective.
Installing ffmpeg from scratch is bound to cause headaches for nearly anyone. NONE of the scripts I found online (dozens) worked correctly as described. Most of the problems with them are incorrect/outdated links. Solutions with GitHub links appear to be the most consistently reliable. Others should be avoided (e.g. hg, which is no longer supported as mentioned above).
In my experience, I configure ffmpeg with x265 in CentOS, it also got error message as
ERROR: x265 not found using pkg-config
After I try this:
$ export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"
I configure and compile ffmpeg successfully with x265. You can try this.
x265.pc sometimes doesn't located in "/usr/local/lib/pkgconfig" and instead it is located in "/usr/lib/arm-linux-gnueabihf/pkgconfig/", so, you needs to include it in the export also .
export PKG_CONFIG_PATH=/usr/lib/arm-linux-gnueabihf/pkgconfig/:/usr/local/lib/pkgconfig/
solution:
add --extra-libs=-lpthread
https://bitbucket.org/multicoreware/x265/issues/371/x265-not-found-using-pkg-config
It's need more library. Please install "libnuma".
I follow to guide from wiki x265
git clone https://bitbucket.org/multicoreware/x265_git
cd x265_git/build/linux
./make-Makefiles.bash
make
And works fine in Red Hat Enterprise Linux 8
You can try
--pkg-config="pkg-config --static"
I believe I found the solution. The issue appears to be that current guide is pulling from master (which may be what a developer wants) but in my case
I actually needed stable. Instead of using the provided command in the current guide:
sudo apt-get install libnuma-dev && \
cd ~/ffmpeg_sources && \
git -C x265_git pull 2> /dev/null || git clone --depth 1 https://bitbucket.org/multicoreware/x265_git && \
cd x265_git/build/linux && \
PATH="$HOME/bin:$PATH" cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX="$HOME/ffmpeg_build" -DENABLE_SHARED=off ../../source && \
PATH="$HOME/bin:$PATH" make && \
make install
Use this command:
sudo apt-get install libnuma-dev && \
cd ~/ffmpeg_sources && \
git -C x265_git pull 2> /dev/null || git clone --depth 1 https://bitbucket.org/multicoreware/x265_git -b stable && \
cd x265_git/build/linux && \
PATH="$HOME/bin:$PATH" cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX="$HOME/ffmpeg_build" -DENABLE_SHARED=off ../../source && \
PATH="$HOME/bin:$PATH" make && \
make install
I can't comment as I have too low reputation. I don't know what it's for :(
Anyway, I had the same problem and I had to do two of tricks mentioned above in solutions:
--extra-libs="-lpthread"
--pkg-config-flags="--static"
Add both of those switches and victory is yours.
I've also come across a case where the x265.pc is not generated, I know this wasn't the issue in original problem but thought worth mentioning.
This occurs if you don't have git installed, in my case I was building inside a container with pre-fetched sources on a corporate network.
This issue is documented at https://bitbucket.org/multicoreware/x265_git/issues/572/pc-file-is-not-generated
It can be worked around either by installing git or fudging it with something as simple as
touch git
chmod a+x git
export PATH="$PWD:PATH"
I am planning to create a new app for personal use on my Mac that uses FFMPEG library, to store a feed from a RTSP IP camera.
Following this official installation procedure from FFMPEG I have manage to successfully achieve the following 2 steps:
To get ffmpeg for OS X, you first have to install ​Homebrew. If you don't want to use Homebrew, see the section below.
ruby -e "$(curl -fsSL
https://raw.githubusercontent.com/Homebrew/install/master/install)"
Then:
- brew install automake fdk-aac git lame libass libtool libvorbis
libvpx \ opus sdl shtool texi2html theora wget x264 xvid yasm
Question:
My question here because I am confused, is how to import a library into Xcode so I can use it in the application I am about to build for my Mac. I can see plenty of GitHub projects related to FFMPEG with IOS/Android, but none for OSX.
All the FFMPEG commands under terminal are working fine, such as converting a video etc.
If you look in /usr/local/Cellar/ffmpeg you will find the actual ffmpeg package and everything in homebrew is just symbolic links to that. For example:
/usr/local/bin/ffmpeg -> ../Cellar/ffmpeg/3.0.2/bin/ffmpeg
Now, if you stay in that directory and do this, you will find all the pkgconfig configuration settings for the constituent parts of ffmpeg:
find . -name \*.pc
./lib/pkgconfig/libavcodec.pc
./lib/pkgconfig/libavdevice.pc
./lib/pkgconfig/libavfilter.pc
./lib/pkgconfig/libavformat.pc
./lib/pkgconfig/libavresample.pc
./lib/pkgconfig/libavutil.pc
./lib/pkgconfig/libpostproc.pc
./lib/pkgconfig/libswresample.pc
./lib/pkgconfig/libswscale.pc
That means you can now find the include path and library paths that you need to put in the Xcode settings. So, for example, if you want the includes for libavutil, you can do:
pkg-config --cflags libavutil
and it will tell you:
-I/usr/local/Cellar/ffmpeg/3.0.2/include
If you want the library settings for libavfilter, you can do:
pkg-config --libs libavfilter
and it will tell you
-L/usr/local/Cellar/ffmpeg/3.0.2/lib -lavfilter
So that is how you get the settings for the compiler/linker. Then you need to put them into Xcode, and I have described that here - look at the bit with the yellow, red and blue boxes.
Hope that helps. Oh, you need to do:
brew install pkg-config
first to get the pkgconfig binary.
In general, you need to configure the Xcode target build settings to add /usr/local/include to the Header Search Path.
Then your #include <ffmpeg.h> (or whatever it's called) will start to work.
Then for linking to libffmpeg.a (or whatever it's called), you can do one of two things:
Add the file to the Additional Libraries and Frameworks of the build settings (selecting it via a file open dialog).
Add /usr/local/lib to the Library Search Paths and -lffmpeg to the Other Linker Flags.
(1. is better if you ask me).
I use Macports, so for me the paths are /opt/local/{include,lib} however with Homebrew there might be an additional level of directory (like /usr/local/ffmpeg/{include,lib}, but you should be able to work that out yourself.
I won't go into details of how to actually use FFMPEG as that is way too involved (and I know nothing about it).
Although this does not answer the specific question here ("how to import such and such libraries"),
for anyone googling here, these days to use FFmpeg in OSX you just
Use the famous import script of Kewlbear
which you can easily find here
https://github.com/kewlbear/FFmpeg-iOS-build-script
and which does everything.
It is a huge amount of non-trivial work maintaining such a build script, and fortunately there's someone who does that work on an ongoing basis.
there are no obvious errors.
the output being similar to building qt 4.8.5 (which I have built succesfully) but the obvious issue is that the bin folder only contains 3 files, moc.exe, rcc.exe, uic.exe
and missing the demos, doc, examples, imports folders etc .. and i cannot find them anywehere else.
i assume the make install step is failing
i'm a bit of a noob :)
i am using these steps to compile -
gunzip qt-everywhere-opensource-src-4.8.3.tar.gz
sudo tar xvf qt-everywhere-opensource-src-4.8.3.gz
./configure -prefix /Users/User/qt4.8.3
make
sudo make install
(i think i've tried sudo on make as well, but can't quite recall exactly)
the makefile seems to have relevant paths
install_qmake: FORCE
#$(CHK_DIR_EXISTS) $(INSTALL_ROOT)/Users/User/Qt4.8.3/bin/ || $(MKDIR) $(INSTALL_ROOT)/Users/User/Qt4.8.3/bin/
-$(INSTALL_PROGRAM) /Volumes/data/qt-creator/qt-everywhere-opensource-src-4.8.3/bin/qmake $(INSTALL_ROOT)/Users/User/Qt4.8.3/bin/
edit..
i went through and compared teh 4.8.3 and 4.8.5 makefiles and apart from the obvious version and directory differences they were identical.
i'm wondering if it's a permission thing and will download a new copy of the source soon and try again.
When attempting to compile RNNLib, I got an error in NetcdfDataset.hpp:26:24 saying that Netcdfcpp.h could not be found. I looked around and found a bug report from 2011 that suggested that this was a bug, but it claimed to have been fixed. I have tried everything I can think of, including rebuilding NetCDF (a dependency of RNNLib) with various different flags, and have been unable to fix this bug. Can anyone give me a hand?
I had some trouble on a virtual machine building rnnlib.
I had to install the C and C++ version of NetCDF to get it to work.
The C version can be installed via sudo apt-get install libnetcdf-dev
I had to install the C++ version by building it.
Hope it will help. It's quite a difficult lib to install.
Maybe this helps someone: you can avoid some of the pain by installing packages from APT, and access the correct version mentioned by user3620756, which contains the netcdfcpp.h header file
. This happens through a legacy package, available on Ubuntun 16.04 (Xenial universe, see APT repository).
First install libnetcdf for C, then install libnetcdf-cxx-legacy-dev which should depend on libnetcdf-c++4 and install required C++ libraries on the go:
sudo apt install libnetcdf-dev libnetcdf-cxx-legacy-dev
The newest version doesn't have this netcdfcpp.h file anymore.
I had to use ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-cxx-4.2.tar.gz to get it working.
I have also followed the same process and it worked for me
"The newest version doesn't have this netcdfcpp.h file anymore. I had to use ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-cxx-4.2.tar.gz to get it working."
After downloading the folder, I had to build it by entering into the netcdf folder. I used simple command for the task :
.\configure
make
sudo make install
But in the file named as "NetcdfDataset.hpp", I have to give the complete path of the netcdfcpp.h file. For my case the path of the include file is :
#include "/Volumes/Macintosh_HD_2/WordSpottingProj/trunk/CODE C++/rnnlib_source_forge_version/netcdf-cxx-4.2/cxx/netcdfcpp.h"
I had this problem in the context of trying to use a makefile that called for netcdfcpp.h:
$ make -f makefile_MAC
c++ -O2 -o burn7.x burn7.cpp -I/opt/local/include -L/opt/local/lib -lm -lnetcdf_c++
burn7.cpp:31:10: fatal error: 'netcdfcpp.h' file not found
#include <netcdfcpp.h>
^
1 error generated.
make: *** [burn7.x] Error 1
I'm on a Mac, so I used Homewbrew to install the NetCDF package, but version 4.3.3.1 didn't appear to have netcdfcpp.h:
brew install homebrew/science/netcdf
However, I found that installing it with an additional flag resulted in this version being included:
brew install homebrew/science/netcdf --with-cxx-compat
I assume that the same is true of other installation/compilation methods, and not that this file has been taken out of versions since 4.2 as others answers state. Maybe it was a default option before and now it isn't?