V4 ieee crc

[michaelni]

Using inversion should protect against added zero bytes before and after a CRC protected "block" of bytes. So this would update the spec accordingly for inversion in v4

[JeromeMartinez]

While changing the formula, wouldn't it make sense to switch to exactly something a lot used, i.e. H.222.0 a.k.a. MPEG-TS (initial value 0xFFFFFFFF, no inversion, in H.222.0 Annex A)? Especially because H.222.0 is publicly available and we could reference it if someone wants more details.

[michaelni]

We could switch to something matching some spec but there are a few things to consider.

1. It should be similar to what we do currently so as to make implementations stay simple, 2 XOR with a constant is quite simple for example
2. We want a good checksum, like prefixed and postfixed 0 byte detection by some means
3. Personally i have a preference of clean and pretty checksums, that is when considering the data and the concatenated checksum the resulting whole produces a 0 checksum, that is the appended checksum does not form a special case. This also has some advantage when trying to correct errors as the checksum does not form a special case. This is true for almost everything ive read in math literature but maybe is not so widely true in real world implementations

[JeromeMartinez]

1. Correct me if I am wrong, but the MPEG-TS related code is:

crc_valid = !av_crc(av_crc_get_table(AV_CRC_32_IEEE), -1, cur_section_buf, tss->section_h_size);
if (crc_valid) {
                    ts->crc_validity[ tss1->pid ] = 100;
}

and current FFV1 related code is:

unsigned crc = av_crc(av_crc_get_table(AV_CRC_32_IEEE), 0, buf_p, v);
            if (crc) {
                av_log(f->avctx, AV_LOG_ERROR, "CRC mismatch %X!", crc);
}

So my proposal would be even simpler than 2 XOR, as it is replacing 0 by -1 if version is 4 (+micro_version), and IIUC we get the same behavior as with MPEG-TS.

2. I don't know enough here so can not argue much, just wondering if using -1 as initial value is not enough for the goal you have.

3. IIUC the MPEG-TS version also produces a 0 checksum.

---

From what I understand for the moment, we would create another less standard CRC-32, so for the moment I would prefer to keep the current method than using another less standard CRC-32. @dwbuiten any opinion?

[michaelni]

the mpeg-ts variant / one that doesnt flip at the end seems to have the problem that appending 0 bytes to a valid block still results in a valid block so such damage would be undetectable (at the checksum level). So if we flip at the start to avoid 0 bytes before it feels very odd not to at the end to do the same for appended 0 bytes