Hi I have a problem with getting ffmpeg libraries to build in my Xcode project. It is in C++ . I have installed it using homebrew and have checked that all the correct libraries have installed via terminal. I have tried with and without extern C as I know it is a c library.
#include <iostream>
#include <opencv2/opencv.hpp>
#include <libavformat>
//extern "C" {
// #include <libavformat>
//}
The linker flags have been set by using (e.g. pkg-config --libs libavcodec) in terminal and these flags do not throw up an error when building. The header files are also found with no problems as the autocomplete flags them top while typing.
Please see attached pictures for Xcode build settings. Really stuck pease help
I identified the problem as being related to the path that the include statement relates to. The header files were one down in the hierarchy from the folders so:
#include <libavformat>
produces an error that the library was not found. The change below sorted the problem out.
#include <libavformat/avformat.h>
Related
The following snippet of ffmpeg-based code is building and working on Windows VC2012, VC20155, VC2017.
With gcc on Ubuntu LTS 16.04 this is giving me issues, more specifically it does not seem to recognize avcodec_send_packet, avcodec_receive_frame and struct AVCodecParameters, and possibly more functions and structures that I'm not currently using.
error: ‘AVCodecParameters’ was not declared in this scope
error: ‘avcodec_send_packet’ was not declared in this scope
error: ‘avcodec_receive_frame ’ was not declared in this scope
The code snippet is:
// the includes are actually in a precompiled header, included in cmake
extern "C" {
#include <libavcodec/avcodec.h>
#include <libavdevice/avdevice.h>
#include <libavfilter/avfilter.h>
#include <libpostproc/postprocess.h>
#include <libswresample/swresample.h>
#include <libswscale/swscale.h>
#include <libavformat/avformat.h>
#include <libavutil/avutil.h>
#include <libavutil/avassert.h>
#include <libavutil/avstring.h>
#include <libavutil/bprint.h>
#include <libavutil/display.h>
#include <libavutil/mathematics.h>
#include <libavutil/imgutils.h>
//#include <libavutil/libm.h>
#include <libavutil/parseutils.h>
#include <libavutil/pixdesc.h>
#include <libavutil/eval.h>
#include <libavutil/dict.h>
#include <libavutil/opt.h>
#include <libavutil/cpu.h>
#include <libavutil/ffversion.h>
#include <libavutil/version.h>
}
//
...
{
if (av_read_frame(m_FormatContext, m_Packet) < 0) {
av_packet_unref(m_Packet);
m_AllPacketsSent = true;
} else {
if (m_Packet->stream_index == m_StreamIndex) {
avcodec_send_packet(m_CodecContext, m_Packet);
}
}
}
...
I read up on the ffmpeg history and learned that on Debian based systems at one point they followed the fork to libavutil when that came about, and then recently some of the platforms switched back to the ffmpeg branch due to the fact that ffmpeg was much more actively supported in terms of bugfixes, features and support. As a result, some of the interfaces were possibly broken.
I've seen git fixes on a library called mediatombs who seem to have ecountered the same if not very similar issues with codecpar (which I initially also had and fixed the same way):
https://github.com/gerbera/gerbera/issues/52
https://github.com/gerbera/gerbera/commit/32efd463f138557c54535225d84136df95bab3dd#diff-af3b638bc2a3e6c650974192a53c7291
Here the commit seems to fix their specific issue by wrapping the codecpar field that is being renamed back to codec, which I also applied and works.
I wonder if anyone knows which functions can be used for the errors given above, since in fact these functions are themselves replacing deprecated functionality according the ffmpeg avcodec.h header comments. (https://www.ffmpeg.org/doxygen/trunk/avcodec_8h_source.html). I hope this does not mean I would have to settle back into avcodec_encode_video2() type of functions?
Update:
For reference, it seems it has also popped up here: https://github.com/Motion-Project/motion/issues/338. The issue seems to be resolved if you can rebuild your ffmpeg stack.
Update:
To resolve the version API mingle, I ended up wiping out any ffmpeg reference and rebuilding ffmpeg from sources. This seems to push things further along in the right direction; I have my source compiling correctly but there is still something wrong with the way I'm linking things together.
Also, I'm using CMake to set up my makefiles, and using find_package for some of the dependencies and handwritten find_path / find_library stuff for everything else. I've seen other people complain about the following linking issue, and a ton of case-specific replies but none of them really shed some light on what the actual problem is. My installed Ubuntu version of ALSA is 1.1.xx but still I get complaints about a 0.9 version I'm supposedly linking. Anyone knows what's wrong with this?
Also, my libasound.so is symbol linked into libasound.so.2.0.0 if that clears anything up. (Hope that double slashed path at the end is correct also).
/usr/bin/ld: /usr/lib/ffmpeg/libavdevice.a(alsa.o): undefined reference to symbol 'snd_pcm_hw_params_any##ALSA_0.9' //usr/lib/x86_64-linux-gnu/libasound.so.2:
So the problem was indeed a version mixup of avcodec and ffmpeg sources, where I would be linking to the right library but compiled against the wrong source package. I found out by following Andrew's suggestion to check the API versions in the header.
The solution was, as halfelf suggested, to uninstall both ffmpeg and avcodec and then manually download the source trunk from the latest repository version of ffmpeg, and build from source. This is quite a process, but it all worked out and resolved the linking issue.
I have an OpenGL file called wglew.h which I downloaded from http://glew.sourceforge.net/. Using the wglew.h as I downloaded it, I receive the following error when compiling a program that I have (I am using MacOSX):
/Users/Downloads/glew-1.11.0/include/GL/wglew.h:70:10: fatal error:'windows.h' file not found
I am trying to go back into the source code of that file and change its dependency from windows.h to something that my Mac could recognize. The source code snippet in the wglew.h file is:
#if !defined(WINAPI)
# ifndef WIN32_LEAN_AND_MEAN
# define WIN32_LEAN_AND_MEAN 1
# endif
#include <windows.h>
# undef WIN32_LEAN_AND_MEAN
#endif
Is it possible to work around this windows.h dependency so that my program does not error out at this step? I asked a similar, but not identical question about a parallel concept at: Where can I get windows.h for Mac? Perhaps instead of looking for an equivalent windows.h file (if such exists for the Mac), I can try to devise a more subtle approach of changing the source code within the wglew.h file to get my program to work and accommodate the windows dependency that I am experiencing?
Here we go again: GLEW is not part of OpenGL. It's a third party library.
You don't need GLEW on MacOS X !
You're barking up the wrong tree!
Instead of trying to fix GLEW (which you don't have to). Just fix your program to not use GLEW when being compiled for MacOS X.
Everywhere in your program where you find a
#include <glew.h>
or
#include <GL/glew.h>
Change it into
#ifndef __APPLE__
#include <GL/glew.h>
#else
#include <OpenGL/gl.h>
#endif/*__APPLE__*/
Put any occurance where a GLEW function is called between a
#ifndef __APPLE__
…
#endif/*__APPLE__*/
block as well.
You don't need GLEW on MacOS X ! Don't use it there.
I used the word hierarchy, but I'm not sure if it's the right one! Let me explain.
I have A.h with:
#include <iostream>
#include <vector>
using namespace std;
I have B.h with:
typedef vector<int> int_vector;
int_vector my_function(int x, int y);
Finally I have X.h, which is:
#include "A.h"
#include "B.h"
And X.cpp:
#include "X.h"
// and the rest
But when I compile that with GCC, it says in B.h, vector not defined and so on. Note that this is an example to explain the problem. The project I'm trying to convert to compile on linux compiles perfectly on Windows under Visual Studio.
I could change the files, but it a 300+ files project, so any help or suggestion that would be incredibly efficient ?
There's nothing wrong with the code that you've posted, and it seems unlikely that there would be a bug of this nature in gcc.
More likely the problem isn't what it seems. For example, it could be that there are multiple A.h (or B.h, or X.h) files in your project, and the wrong file is being included somewhere.
My advice would be to run one problematic .cpp file through the preprocessor (gcc -E) and examine the result. That will tell you exactly what is being included when.
For a week I've been struggling with compiling openCV programs. I've tried everything I could possibly find on the internet.
What I did is: I've downloaded OpenCV-2.3.1-win-superpack.exe and followed this official installation guide.
In the CMake (gui) my source was: D:\opencv and build destination was: C:\opencv.
I've also added C:\opencv\install\bin;C:\opencv\bin to my system's PATH variable.
What I want is to compile openCV programs on my Windows OS using MinGW's gcc/g++ compilers.
I've tried various gcc/g++ parameters that I've found on the internet and days playing with the -I and -L options the compiler can never find the openCV functions or structures.
What I am trying to compile:
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <cv.h>
#include <highgui.h>
int main(int argc, char *argv[])
{
// Nothing but create a window
cvNamedWindow("mainWin", CV_WINDOW_AUTOSIZE);
cvMoveWindow("mainWin", 100, 100);
cvWaitKey(0);
return 0;
}
Error:
Input:
gcc test.c -o test -I"C:\opencv\install\include" -I"C:\opencv\install\include\opencv" -L"C:\opencv\install\bin"
Output:
...\ccK4MfHv.o:test.c:(.text+0xa0b): undefined reference to `cvFree_'
Or with g++:
Input:
g++ test.c -o test -I"C:\opencv\install\include" -I"C:\opencv\install\include\opencv" -L"C:\opencv\install\bin"
Output:
...\ccXCTKa1.o:test.c:(.text+0x1e): undefined reference to `cvNamedWindow'
Side note: trying to compile in VS2005 I get the same error.
Thank you for your time!
In case someone else needs to solve this issue, here's how I got the posted OpenCV/HighGUI sample code to compile in Windows 7 x64 using MinGW, MSYS, and CMake:
build OpenCV from source using MinGW/MSYS/CMake. This is because I could not get the MinGW compiled version in the OpenCV-win-SuperPack to link properly in MinGW/MSYS/Windows 7 x64.
For full reference, here's how I compiled OpenCV:
make sure you have an up-to-date CMake (v2.6 or later) and MinGW (with GCC, G++, and MSYS options) installed
if you want the new Qt-based OpenCV HighGUI front-end, you will need to install Qt 4 (SDK).
download a OpenCV source/superpack version 2.2 or later (I used OpenCV-2.3.1-win-superpack.exe)
unzip the contents to [OPENCV_SOURCE_DIR] (I put it in C:/opencv, so there should be a file at C:/opencv/README for example)
create a [OPENCV_BUILD_DIR] directory elsewhere (I used C:/opencv/build/mingw)
use the CMake-GUI tool, specify the source directory as [OPENCV_SOURCE_DIR], the build directory as [OPENCV_BUILD_DIR], and click "Configure".
you may wish/need to go tweak the options (e.g. I ticked "Qt" and "Qt-OpenGL" entries, then clicked "Configure" again, then had to provide the path to the qmake executable)
once you have finished configuring OpenCV, click "Generate"
in a MSYS terminal, browse to [OPENCV_BUILD_DIR], and run "make" to build the code (this may take a while)
once the has been built properly, run "make install", which collects the built code/libraries/include dirs into [OPENCV_BUILD_DIR]/install folder (or a different folder if you changed the corresponding option when using the CMake-GUI tool)
add [OPENCV_BUILD_DIR]/install/bin folder to the PATH environmental variable. If you do not know how to do this, then I'd recommend using the Path Editor GUI tool.
if you end up using Qt, you will also need to put the bin folder of Qt SDK in the PATH environmental variable. This is the folder that includes qmake.exe.
put the following sample code into a file called test.c. I modified the includes slightly to make them compatible with OpenCV v2.2 and above.
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <opencv/cv.h>
#include <opencv/highgui.h>
int main(int argc, char *argv[])
{
// Nothing but create a window
cvNamedWindow("mainWin", CV_WINDOW_AUTOSIZE);
cvMoveWindow("mainWin", 100, 100);
cvWaitKey(0);
return 0;
}
in a MSYS terminal, browse to the folder where you put test.c, and run:
gcc -o test -I"[OPENCV_BUILD_DIR]/install/include" test.c \
-L"[OPENCV_BUILD_DIR]/install/lib" \
-lopencv_core[OPENCV_VERSION] \
-lopencv_imgproc[OPENCV_VERSION] \
-lopencv_highgui[OPENCV_VERSION]
So in my case:
gcc -o test -I"/c/opencv/build/mingw/install/include" test.c \
-L"/c/opencv/build/mingw/install/lib" \
-lopencv_core231
-lopencv_imgproc231
-lopencv_highgui231
Path Editor: http://www.redfernplace.com/software-projects/patheditor/
You have the directory, C:\opencv\install\bin, to locate libraries on the gcc/g++ command line, but I think you'll also need to specify the libraries to use as linker inputs as well. I'm not sure what libraries are part of the OpenCV distribution, but going by the example on the instruction page you linked to, one might be:
-lopencv_calib3d220.dll
You'll probably have to add one or more other ones (that follow the name pattern lib*.a in the C:\opencv\install\bin directory - or maybe some other lib directory that you should be passing in a -L option).
I am trying to compile a Cocoa app in xcode 4.0 and I'm getting this error...
fatal error: 'string' file not found
...when trying to compile to .pch file on this line:
#include <string>
I have another xcode project that does the same thing, but does not get the error. I have scoured the build settings for some different, but I can't find one. The only difference is that the project that compiles OK was started as a command line project, not a Cocoa project, but the build setting are the same.
The target OS is Mac OS X 10.6
The error happens when compiling the precompiled header and doesn't get to any of the other files. The only framework that the compiling version has is Foundation.framework and the non-compiling one has it as well.
Why is it not finding in one project and not the other? Any advice?
What is the extension of your source files? If it is ".m", try to change it to obj-cpp ".mm", so that Xcode will deduce correct language.
Or just put c++-specific headers inside "#ifdef __cplusplus" block
Update
The guard must exist for each language compiled in the project because this specific include is in the pch. IOW, if it were all c++ and/or objc++ there would be no error. Evidently, there is at least one file that does not recognize C++ (e.g. C or ObjC sources are also compiled in the target). Therefore, you simply guard it like so:
// MONPrefix.pch
#ifdef __cplusplus
#include <string>
#endif
// same for objc, so your C and C++ sources compile with no error:
#ifdef __OBJC__
#include <Foundation/Foundation.h>
#endif
string is a C++ header (for std::string). If you are looking for stuff like strcpy you need to include string.h