obolo / freeraptor Goto Github PK

When I tried this program by setting K = 64 or 128, the precoding matrix became singular, which was quite abnormal as rfc5053 guaranteed that the matrix must be invertible.
The bug comes from the way of defining S (the number of LDPC symbols) in r10_compute_params of raptor10.c. It doesn't match the definition in rfc5053, where S is the smallest prime integer such that S >= ceil(0.01*K) + X.

As the guidelines in RC5053 specify, build the so called generator matrix A, needed for obtaining the intermediate symbols.

A test main to be built in the Makefile. Just for building something.

The types used by the raptor encoder/decoder need to be set up, along with the basic functions

The path of execution in r10_multiplication depends on the value of variable beg. The said value is set once and never modified later. Unsurprisingly that results in one operation res_block[i + t] = res_block[i + t] ^ block[j + t]; never being executed.

Currently raptor10.c contains many arguments to the functions which are never accessed or variables which are assigned value and again, ignored later.
While it would be trivial to simply delete them, they might indicate incomplete implementation of the RFC. For this reason, they should be reviewed one by one. Not to overcrowd the issue list, I created a list of functions to review. An element should be marked as complete, once all arguments and variables are accessed or it is clearly stated in the comment why they are not.

• r10_Trip
• r10_build_LDPC_submat (initial value is instantly overwritten)
• r10_build_Half_submat
• r10_build_LT_mat
• r10_LTEnc
• r10_decode

The Raptor10 structure defines many, if not all packet fields defined in the RFC. Ideally, their values would be trusted from the structure initialisation. Unfortunately that is not the case. The value of L (defined in the structure as well) is recalculated locally in r10_Trip, r10_build_LT_submat and r10_build_LT_mat. This is troublesome, since no indication is given whether this is done on purpose or as an oversight. If the first one is true, shouldn't the value be updated in the structure?

Other problems arise:

1. In r10_build_LT_mat one can only use Raptor10 structure to calculate L, in r10_Trip K is passed as an argument and in r10_build_LT_submat it's K, S and H. All of them get a pointer to the Raptor10 structure. What values should be used in these situations? The ones passed as the arguments or from the structure? Again, if the first ones, why isn't the structure updated? Such mix of pseudo-functional and imperative code is confusing and might introduce errors, that will be very hard to trace. After all, we use some K, S or H each time. If a function is supposed to have the notion of Raptor10, then it probably shouldn't directly adhere to the RFC demanding an argument of K; the reverse is true as well.
2. The malpractice of copy-pasting sections of code contributes to the problem described in #13 For example in r10_Trip a local value of L is calculated, but it is never accessed as the line directly under it uses L from Raptor10 structure adding even more complexity and making chances of errors even higher for the reasons described in point number 1. I'd separate these calculations into a separate function already, if not for the fact, that performing this operation in the functions other than the setup is a source of concern already.

C++ not best fit anymore. Better to switch to C.
Maintaining structure of:

• class implementing GF(2) matrix;
• class implementing codec.
• any other utility class.

The software will initially use good ol' Gaussian Elimination