error: ‘avcodec_send_packet’ was not declared in this scope - gcc

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.

Related

Problems with ffmpeg build in Xcode

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>

Error: identifier "MAXFLOAT" is undefined

I am trying to convert a Xcode project (link) to a VS2008 solution.
In a cuda filetype .cu, the term MAXFLOAT is used. I am adding the following headers but the error is not resolved.
#include <stdio.h>
#include <math.h>
In the Xcode project, I tried to locate the definition but there is none. Also this term is only used in this file. Is this something specific to Xcode?
MAXFLOAT is a non-standard parameter. Use one of the following, portable alternatives:
In C: use the standard library FLT_MAX (defined in <float.h>).
In C++: use std::numeric_limits<float>::max (defined in <limits>). You may still use C's FLT_MAX, but include <cfloat> instead.

How can I change an OpenGL source code file?

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.

MEX compile error: unknown type name 'char16_t'

I cannot compile any MATLAB MEX code due to the following error:
In file included from /Applications/MATLAB_R2013a.app/extern/include/mex.h:58:
In file included from /Applications/MATLAB_R2013a.app/extern/include/matrix.h:294:
/Applications/MATLAB_R2013a.app/extern/include/tmwtypes.h:819:9: error: unknown type name 'char16_t'
typedef char16_t CHAR16_T;
The only thing that has changed on my machine as far as I can remember is that Xcode was updated to version 5.1 (5B130a).
Any fix for the time being to compile MEX code in MATLAB?
[Running on OS 10.9.2 with Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)]
By default, the upgraded Clang doesn't set char16_t, which is required by MATLAB.
Quick fix
This works for C or C++ code but needs to be done on each mex command line.
>> mex -Dchar16_t=uint16_t ...
Other solutions below put this definition into the mex configuration or enable C++11.
Permanent solution
Options:
Add -std=c++11 to CXXFLAGS in your mex configuration file AND compile .cpp files instead of .c. The mex config file is mexopts.sh (pre-R2014a) or the .xml file indicated by mex -setup (R2014a+). This is what worked for OP, but the next option works too. Be sure to edit the active/installed config, not the system-wide reference. Try the next solution if you can't tell.
Use a #define or typedef to create char16_t before including mex.h (see "other workaround" below).
In some future version of MATLAB, this will have been fixed. Re-run mex -setup to have MATLAB reconfigure it for you and it works. As of R2014a, this doesn't do the trick.
As a last resort, you can always modify the MATLAB installation, hacking MATLAB's tmwtypes.h as Dennis suggests, but I strongly suggest NOT modifying the MATLAB installation.
Note: If you are using C and cannot or don't want to change to C++, follow the solution in this other answer, OR see the alternative workaround below.
The other workaround
If for some reason you are not able to enable the C++11 standard, you can use the preprocessor to define char16_t. Either put #define char16_t uint16_t before #include "mex.h", or set it with the compiler command line:
-Dchar16_t=uint16_t
Alternatively, use a typedef, again before including mex.h:
typedef uint16_t char16_t;
If these solutions don't work, try changing uint16_t to UINT16_T. Further yet, others have reported that simply including uchar.h brings in the type, but others don't have that header.
I experienced the same error, also directly after upgrading to Xcode 5.1.
The relevant lines (818-824) in the file tmwtypes.h, which causes the error, are:
#if defined(__STDC_UTF_16__) || (defined(_HAS_CHAR16_T_LANGUAGE_SUPPORT) && _HAS_CHAR16_T_LANGUAGE_SUPPORT)
typedef char16_t CHAR16_T;
#elif defined(_MSC_VER)
typedef wchar_t CHAR16_T;
#else
typedef UINT16_T CHAR16_T;
#endif
A solution is to simply change the line
typedef char16_t CHAR16_T;
into
typedef UINT16_T CHAR16_T;
A must admit that I don't know if this affects any function or behaviour of mex files but at least I'm able to compile my c files again using mex.
Please see other answers if this method doesn't work.
I upgraded my gcc/g++ compilers using homebrew to version 4.8 --> gcc-4.8 and g++-4.8.
After that I changed the following lines in the mexopts.sh file:
CXXFLAGS="-fno-common -fexceptions -arch $ARCHS -isysroot $MW_SDKROOT -mmacosx-version-min=$MACOSX_DEPLOYMENT_TARGET -std=c++11"
In my mexopts.sh, this is line 150. I only added the -std=c++11 flag which is what I guess chappjc meant.
EDIT: This is covered in the update by chappjc!
I just add my own experiment (C++ only). The
#define char16_t uint16_t
was causing some problem in the other parts of the mex file. In fact, subsequently to my mex file, char16_t was properly defined. By tracking the chain of includes, the proper type char16_t is set in a file named __config :
typedef __char16_t char16_t;
which is also the first file included from <algorithm>. So the hack consists in including algorithm before mex.h.
#include <algorithm>
#include "mex.h"
and the proper settings are performed, still in a multiplatform manner and without changing anything in the build configuration.
Include uchar.h before including mex.h...works fine. Also, the answer above (adding -std=c++11) only works for c++, not c.
#include <uchar.h>
#include "mex.h"
As part of XCode 5.1.1 char16_t is defined in __config, which is called from typeinfo.
You can add
#include <typeinfo>
before
#include "mex.h"
to have char16_t defined.
This post might help: http://www.seaandsailor.com/matlab-xcode6.html
It was easier than I thought. Just replace all 10.x with your OS X version and add -Dchar16_t=UINT16_T to CLIBS in mexopts.sh file.
It worked on OS X 10.9 Mavericks with Xcode 6 installed.

gcc don't respect hierarchy of include files

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.

Resources