The OpenFEC project has been launched by the INRIA, CEA, and ISAE. These organizations have jointly released the CeCILL license family in July 2004, with the goal to have licenses in conformance with the French law and compatible with the GNU GPL/LGPL family. You can find more information on the CeCILL website.

Consequently all resources whose copyright is owned by INRIA, CEA, and ISAE are distributed under the CeCILL-C flavor of the CeCILL license family. This CeCILL-C is similar in spirit to the GNU LGPL (Lesser GPL) license, which means that many possibilities are offered to the end user. It should therefore suit most situations.

Note also that resources that are not copyrighted by INRIA, CEA and ISAE are distributed under their original license, with their original copyright. This is the case for source code coming from Radford NEAL and Luigi RIZZO. Please see the licenses section for more information. However our feeling is that here also the provided license should suit most situations.

The OpenFEC project relies on the CMake tool to build all binaries. CMake allows you to simply and automatically generate a set of makefiles just by running the "cmake .." command from the build directory. Once the makefiles have been generated, you can then compile everything using "make" inside the same build directory.

Additionally, you can use the "make test" command to run automatically a high number of validation tests (CMake does more than just compiling libraries and executables!). These tests are non regression tests, not performance evaluation tests. By default, only the stable codecs are considered by the tests. If you want to test the advanced codecs, you just have to modify the tests/CMakeLists.txt file.

Please read the README file at the root directory of the distribution for additional information on how to use CMake.

This is perfectly normal. By default, as long as fresh new symbols arrive, they are given to the ITerative decoder (IT) which is extremely fast but does not feature optimal recovery performance. In your case, the IT decoder succeeded after receiver 1.111328*k = 1138 symbols (since k=1024).

LDPC-Staircase can do much better if one forces the library to finish decoding with ML (in our case Gaussian Elimination) decoding. An easy way to do that with eperftool is to specify a loss rate and to increase it progressively until reaching the minimum overhead (for a given code and transmission pattern). For instance, in your case:

$ eperftool -codec=3 -k=1024 -r=512 -seed=2 -loss=3:508
./eperftooleperf_tool: an extended AL-FEC performance evaluation tool
[...]
tot_nb_source_symbols=1024  tot_nb_repair_symbols=512  symbol_size=1024  ldpc_N1=5
[...]
nb_received_symbols=1028  inefficiency_ratio=1.003906

It represents a 0.39% overhead, that's great!