> to use this scheme encoding realworld data you cannot guarantee, that there wil be no

> such input packets.

This specific scheme needs one 0 bit per packet in worst case, this does not seem to be a big issue, any real world case will need many bits for header data, one bit more isnt much.

> Second, position need to be stored with RS-codeword for decoder, but it will be not

> protected by code, if transmitted in the same packet, so you need to encode this

> position also and transmit in some other packet (and recursively on).

The position is fixed, its a design decission where to place it. Its not transmitted thus not affected by any possible damage.

> Third, is there any guarantee, that you will _always_ find at least yv values of

> selected input symbol, that will not give 2^x+1 codes as parity symbols? Are there any

> proves of this?

yes, you can proof this by looking at the opposite, that is how many values of a single symbol can produce a 2^x+1 for a specific parity symbol (the awnser is 1) so for n-k parity symbols only n-k values of any specific symbol can produce any 2^x+1 anywhere

]]>First, it will not work if all input data consist of binary 1’s. And if you are planning to use this scheme encoding realworld data you cannot guarantee, that there wil be no such input packets.

Second, position need to be stored with RS-codeword for decoder, but it will be not protected by code, if transmitted in the same packet, so you need to encode this position also and transmit in some other packet (and recursively on).

Third, is there any guarantee, that you will _always_ find at least yv values of selected input symbol, that will not give 2^x+1 codes as parity symbols? Are there any proves of this?

So, it’s not that trivial to store these 2^x+1 codes, I think…

]]>