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.
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!
Another method, since release 1.4.0, is to use the -find_min_overhead argument to eperftool (you'll also have to provide a seed of your choice). In that case the minimum overhead is automatically searched, in an iterative way:
$ eperftool -codec=3 -k=1024 -r=512 -seed=2 -find_min_overhead [...] ===> (1) test with 1024 recvd symbols (overhead 0) and 512 lost symbols... failed ===> (1) test with 1034 recvd symbols (overhead 10) and 502 lost symbols... OK ===> (2) test with 1025 recvd symbols (overhead 1) and 511 lost symbols... failed ===> (2) test with 1026 recvd symbols (overhead 2) and 510 lost symbols... failed ===> (2) test with 1027 recvd symbols (overhead 3) and 509 lost symbols... failed ===> (2) test with 1028 recvd symbols (overhead 4) and 508 lost symbols... OK [...] nb_received_symbols=1028 inefficiency_ratio=1.003906
Note that the two techniques do not use the same transmission schedules, so the results may slightly differ. This is normal.
Yes, there is a simple client/server demo application. See applis/howto_examples/simple_client_server (version 1.4.1 and higher).
+--------------+ +--------------+
| SERVER | | CLIENT |
+--------------+ +--------------+
|{set of source| |{set of source|
| symbols} | | symbols} |
| | | | ^ |
| v | | | |
| FEC encoding | | FEC decoding |
| | | | ^ |
| v | | | |
| UDP sendto | | UDP recvfrom |
| | | | | |
+------|-------+ +------|-------+
| UDP connection |
+------------------------------------+
signaling traffic + data traffic
Note that this is only a rudimentary functional example. Several things are missing there since the goal is only to provide a minimum example.