feature requesr for build system
Status: Beta
Brought to you by:
jsanpedro
Menu
▾
▴
Hi all
I am just interested in the C++ Api and I really like the SCON based build system. I use MSVC and I would like to use just on fobs DLL, which contains all the libs I have enabled when compilng ffmpeg with MINGW. I would be great if FOBS would have a build option, where I can enable generation of of a fobs dll (but no JMF-Stuff) and a MSVC-compliant fobs.lib for linking (as it is done in ffmpeg when compiling with --enabled-shared, see also at: http://www.mingw.org/mingwfaq.shtml )
regards
Roberto
Hi Roberto,
about building Fobs but not Fobs4Jmf, it is already possible using the FOBS4JMF=no option (more info in the documentation section of the web page). You can add the following lines to the SConstruct script in the src/cppapi folder to get the .dll and .lib files:
if env['PLATFORM'] == 'win32':
env.Prepend(LINKFLAGS = ['-shared','-Wl,--output-def,lib/libfobs.def']);
env.Program(['#lib/libfobs.dll','#lib/libfobs.def'],Split('PacketBuffer.cpp Decoder.cpp Encoder.cpp Transcoder.cpp Error.cpp'))
env.Command(['#lib/libfobs.lib','#lib/libfobs.exp'], ['#lib/libfobs.def','#lib/libfobs.dll'], 'lib.exe -machine:i386 -def:$SOURCE -out:$TARGET')
I haven't try it but it should work fine as long as you have the lib.exe microsoft tool somewhere in the PATH.
Cheers
Jose San Pedro Wandelmer
Hi Pedro
I tried to add those lines, but I got a lot of "undefined reference errors". Do you have any idea what is missing ? Does anything special need to be considered when compiling ffmpeg ?
regards
Roberto
Hi,
add this code to the end of the Sconstruct file:
if env['PLATFORM'] == 'win32':
<tab>env.Prepend(LINKFLAGS = ['-shared','-Wl,--output-def,lib/libfobs.def']);
<tab>env.Program(['#lib/libfobs.dll','#lib/libfobs.def'],Split('PacketBuffer.cpp Decoder.cpp Encoder.cpp Transcoder.cpp Error.cpp'),LIBS=ffmpeg_lib_deps)
<tab>env.Command(['#lib/libfobs.lib','#lib/libfobs.exp'], ['#lib/libfobs.def','#lib/libfobs.dll'], 'lib.exe -machine:i386 -def:$SOURCE -out:$TARGET')
Some considerations:
1 - Replace <tab> with real tabs
2 - You will need probably need to comment some lines in the SConscript file... It seems that scons does not feel happy if the same set of .cpp files is used twice in the script
3 - Note the LIBS parameter added. The code I sent you yesterday won't link ffmpeg to the DLL and that explains the undefined reference errors.
4 - The DLL may not be compatible with MSVC. That's because it seems gcc and msvc use different naming conventions for c++ symbols. This is not the case when using a pure C api for the dll. Perhaps things have changed since the last time I had a look but it is very likely that you will need to code a C wrapper for the functions you need from the Decoder or Encoder.
Will try to make out a cleaner solution to include it in the next release.
Cheers
Jose San Pedro Wandelmer
Pedro, thanks for the hints, now I got a fobslib.dll and a fobslib.lib. One thing is strange: fobslib.dll has just 1 MB Filesize. (just avcodec.dll is usually more than 2 MB). Well, next I need to find out, how to use it from MSVC. I just took the fobs test.cpp and tried to compile it from MSVC. First I had to add the main ffmpeg headers. But then I got stucked with a missing "inttypes.h". Do I need to mess with compiler directives somewhere ?
And what do you mean by C wrapper for Decoder/encoder functions ? Ain't am loosing all the beauty of fobs with that ?
regards
Roberto
Hi Roberto,
first of all, please call me Jose ;)
About the size of the .dll, I've just built it and it was above 10MB. Please, take a closer look to the file size and rebuild it just in case.
About MSVC, I had no problems to compile but I always used the command line (msys). inttypes.h is included in the Msys distribution, so you'd better try it from the command line. Anyway, you'll need to include header files from ffmpeg and fobs, as these are mandatory.
Lastly, about naming conventions, I can tell you that i have been unable to get MSVC recognize Fobs symbols names because C++ symbols are named differently by gcc (msys) and msvc. This is not the case when using plain C. Of course, doing a C wrapper is not the best solution, but it did the trick for me once upon a time. And besides, only the entry points of the funcitons must be C, so the implementation is straightforward. If you get the C++ DLL to work, please report back the details!!
Cheers.
Jose San Pedro
Pedro, I just sorted out the problem with "inttypes.h" by creating one, and defining there those inttypes. But then came what you expected: 15 linking errors with unresolved external symbols.
regards
Roberto
Jose, I had just posted the last message before seeing your post about correcting me how to call you, sorry fro that. I still did not get completly how to wrap those entypoints, can you point me to an example ?
About the filesize, I don't have additional libraries right now, as you have it in fobs4jmf, but I don't know if this explains the huge difference.
Regards
Roberto
Hi Roberto,
maybe you haven't enabled debug symbols.... This could be the real cause of the size difference.
About the C wrapper, I really encourage you to avoid the use of MSVC. In case this is not an option, depending on your applications you will have to create some C entry points.
Define an initializer like this:
void *init_decoder(options)
{
Decoder *d = new Decoder(...);
return (void *)d;
}
The rest of your functions will use the pointer returned by this init function. For instance:
void close_decoder(void *dec)
{
Decoder *d = (Decoder *) dec;
d->close();
}
I would suggest to create few entry points, if your application is fine with that. For instance, let's imagine you need to extract the first 25 frames of a video file. You could do smth like this:
void extract_first_25_frames(videoname)
{
Decoder *d=new Decoder(videoname);
/*code to extract frames*/
d->close();
return;
}
I tell you that because creating an entry points for each method of the Decoder class will be really tough. In addition, the API is subject to changes and that will force you to keep both APIs synchronized. That's too bad.
IMPORTANT NOTE. When creating your wrapper, the code must be a cpp file (because you make use of Fobs Objects). It is the header file which contains the C declaration. To make g++ create plain C symbols you have to enclose the function declarations this way:
extern "C"
{
void f1();
void f2();
}
Once you have your .cpp and .h files, use them to create the DLL by editing the Sconstruct file in src/cppapi.
There's maybe a way for MSVC to understand C++ symbols generated by g++, but I really don't know how. If you find ( or anybody else) please tell us!!!
Cheers!
Jose San Pedro
Jose, thanks very much for the replay. Regarding filesize, you are right, I had no debug symbols enabled. I will build the wrapper as described and I will also try to compile my application directly with mingw and I will post the results (or problems along the way)
regards
Roberto
Jose, another thing I could do (in case I stick to MSVC for the application), is to compile fobs C++ Api with MSVC. Well , I would loose the beauty of scons, but at least I would not need another wrapper. What do you think about that approach ?
regards
Roberto
Hi Roberto,
your solution may work. However, I don't know if MSVC will be able to link to the ffmpeg .dll's (avcodec.dll and avformat.dll) and to compile using ffmpeg headers. If you use additional libraries (faad, faac, ogg-vorbis, etc) the risk of finding compilation problems grows.
Tell us about your experience if you try it!
Thanks a lot!
Cheers.
Jose San Pedro