We have a C++-based application that runs on Windows, Mac, and Linux. I now need to add h.264 and h.265 decoding within this application. It seems ffmpeg will do the trick.
As ours is a commercial application, we cannot disclose the source code to public. However, as I understand, FFMpeg is based on LGPL licensing requirements. Going through various articles on LGPL requirements, it seems I can use ffmpeg without disclosing our source code as long as:
I build ffmpeg as a shared libraries and make sure that I don't use "--enable-gpl" flag during configuration.
I acknowledge in our About dialog box that we are using ffmpeg shared libraries.
Can someone please verify if this more or less meets the requirements? Regards.
Note that I need ffmpeg only to decode and not to encode. Therefore, I don't have to use "--enable-libx264" and "--enable-libx265" flags.
As a FFmpeg developer, I would expect you to follow the considerations mentioned on our website:
Compile FFmpeg without "--enable-gpl" and without
"--enable-nonfree".
Use dynamic linking (on windows, this means
linking to dlls) for linking with FFmpeg libraries.
Distribute the
source code of FFmpeg, no matter if you modified it or not.
Make
sure the source code corresponds exactly to the library binaries you
are distributing.
Run the command "git diff > changes.diff" in the
root directory of the FFmpeg source code to create a file with only
the changes.
Explain how you compiled FFmpeg, for example the
configure line, in a text file added to the root directory of the
source code.
Use tarball or a zip file for distributing the source
code.
Host the FFmpeg source code on the same webserver as the
binary you are distributing.
Add "This software uses code of FFmpeg licensed under the LGPLv2.1 and its source can be downloaded here [where here is a link to the source code]" to every page in your website
where there is a download link to your application.
Mention "This
software uses libraries from the FFmpeg project under the LGPLv2.1"
in your program "about box".
Mention in your EULA that your program
uses FFmpeg under the LGPLv2.1.
If your EULA claims ownership over
the code, you have to explicitly mention that you do not own FFmpeg,
and where the relevant owners can be found.
Remove any prohibition
of reverse engineering from your EULA.
Apply the same changes to all
translations of your EULA.
Do not misspell FFmpeg (two capitals F
and lowercase "mpeg").
Do not rename FFmpeg dlls to some obfuscated
name, but adding a suffix or prefix is fine (renaming "avcodec.dll"
to "MyProgDec.dll" is not fine, but to "avcodec-MyProg.dll" is).
Go
through all the items again for any LGPL external library you
compiled into FFmpeg (for example LAME).
Make sure your program is
not using any GPL libraries (notably libx264).
From what you've said so far, I think you're doing only point 1-2, 9-11, 15-18. You need to make the source code (of FFmpeg) including modifications (3-5, 7-8) available along with your application, mention build instructions (6), remove ownership claims on FFmpeg, remove reverse engineering prohibitions (if any), and check your EULA (12-14).
Yes, with lgpl you can use it as a dll/shared lib and you won't need to make your source code available.
But you should be aware that it's not the licensing of the code is the issue for commercial use, but the patents around h.264/h.265 and you need license for that. AFAIK, even if you simply want to decode you'll still need to have license.
MPEGLA is the licensing body for h264 codec patent pool.
Related
I'm using ffmpeg lib.
I try #include "libavutil/internal.h" but received error 'libavutil/internal.h' file not found.
What should I have to do?
FFmpeg is a C application (mainly). But still support some object orientation features like information hiding (Encapsulation).
You should stick with the exposed interface (API - libav). There is a good reason for this. The header and its functions as the name suggest is "internal". Not safe to use (may change, etc..).
Have you installed ffmpeg?
First, ffmpeg is a software, not a library. It contains several libraries such as libavutil.
Then, once ffmpeg is installed, look if it's in your library path.
I suppose you're trying to compile with gcc/g++, so, you can also try to add -I[dir_where_libavutil_is]
Of course, you need libavutil-dev installed in your system.
From what I understood here, if I compile with the flag --enable-gpl, ffmpeg can be added in a commercial product.
In the recipe, there is: PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl"
Thus, I created a ffmpeg_%.bbappend containing:
PACKAGECONFIG_append ="gpl"
But it seems I still have to put a value in LICENSE_FLAGS_WHITELIST, most likely commercial. Is it a mistake from me or is it not handled properly by the main recipe?
Thanks
No, it's not a mistake.
The PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl" just adds a way to enable/disable building GPL-licensed parts of ffmpeg. It has nothing to do with whether you can use the result in a commercial product.
By setting LICENSE_FLAGS_WHITELIST_append = " commercial_ffmpeg", you're telling the buildsystem that you're allowed to build and use ffmpeg. That can be due to you having acquired a commercial license (or licenses), that you'r in a jurisdiction where you don't need commercial license(s), etc...
Note that in this case, these two PACKAGECONFIG[gpl] and LICENSE_FLAGS_WHITELIST are orthogonal, they have nothing with each other to do.
The LICENSE_FLAGS_WHITELIST is there to protect you, from adding things that might require commercial licenses by mistake / unknowingly.
I'm trying to build a project (namely, Angband's source - http://rephial.org/downloads/3.3/angband-v3.3.2.tar.gz) with Emscripten's emcc in order to port it to Javascript and ultimately build an online version.
I've managed to get the process started with
emconfigure ./configure
make
which begins to successfully start generating LLVM bitcode .o files, but then it hangs up on main-gcu.c with 'main-gcu.c:43:11: fatal error: 'ncurses.h' file not found'
I believe main-gcu.c is the only file that references ncurses, but I just can't figure out how to include the library while compiling. Is there a way to specify including ncurses with 'make', or should I compile the main-gcu.c file individually, with 'emcc main-gcu.c -c -lncurses'? I tried doing that but that led to another error with emcc being unable to find other actually included header files two levels down (it couldn't find headers that were included by a header included by main-gcu.c - anyway to fix that?).
I'm also not certain if I have/need to install the ncurses library on Mac OSX. All I can really find are references to libncurses5-dev for Linux.
Thanks!
I think you misunderstand the compilation via Emscripten. I will try to point out a few problems you are facing.
The general rule is that all tools of Emscripten ONLY can turn LLVM formats (e.g. BITCODE) into JavaScript. emconfigure, emmake, ... modify the build environment so that your sourcecode is compiled to one of the LLVM formats (there are exceptions to the rule but nevermind). So anything you want to link against your final result has to be in a LLVM format, as well (which by default ncurses is not).
Since the output is JavaScript, there is no chance to execute any program code in different threads. While a lot of C/C++ code does use a thread for the UI and others for processing, such a model does NOT work for Emscripten. So in order to get the software compiling/running you will have to rewrite the parts that use threading. See emscripten_set_main_loop for pointers.
Even if you have the libraries compiled you then have to statically link them to Emscripten. At this point it is less of a technical problem but more of a license issue since if your library is licensed under e.g. LGPL due to static linking the GPL terms are effective.
I hope all clarity finally vanished ;)
My question may be silly, but I need to use a library from its source code without compiling it to a library form first. The tool in question is FreeType. Is this possible?
You can add all the files from the FreeType source distribution into your own project, and try to get them to compile alongside. However, the FreeType compilation procedure is a bit tricky, if I recall correctly.
It is probably easier to compile FreeType as a static library, then link your own program with the generated library. If you do that, your executable will have no dependency on the FreeType runtime library.
It's called bundling: instead of shipping your code with JAR files of some library, or even just requiring the library in your INSTALL document, you simply copy the source code into your project and have it built by your build system instead of using it pre-built. It may require adapting your build system a bit, and you need to make sure you have the right to redistribute the library in source form, but it can sometimes make sense.
MPlayer did this with ffmpeg for a long time, and XEN with the Linux kernel (notionally, they ship patches instead of the entire kernel tree). The disadvantage is, of course, that you effectively fork the library, and don't get any updates of the code whatsoever unless you re-rip their code and get it to build in your project again.
You can get the sourcecode of FreeType from http://freetype.sourceforge.net if that's what you mean.
Tasked with converting wav to mp3 in my mac program, I've downloaded and compiled the LAME encoder. I was wondering how I then use it in my xcode project? Previous 3rd party libraries have been in the form of a framework, but LAME just produces a dylib.
Thank you.
The use of a dynamic library is similar to a Framework Apple doc on dynamic libraries
The library will need to be in a known place
In the target build options set the header and library search paths. To use the library drag it into Xcode (These set the -I -L and -l options to the compiler)