ContinuityAnalyzer: duplicate packet checking may be too simplistic

[alevinsn]

In the ContinuityAnalyzer class's feedPacketInternal() method, if it encounters a case in which the CC value is the same as that of the last input packet and it has a payload, it assumes that this packet must be a duplicate of the last packet. Per the standard, that should be the case, but other situations could arise in buggy transport streams. Without doing a memory compare of the original input packet and the current input packet, there is no way to know that they are actually duplicates. If a memory compare were to return false, then that would be an indication of a different error, that the CC value didn't increment, but it should have been incremented because the packets aren't duplicates.

Maintaining the last input packet, per PID, is warranted for addressing issues with the class when used in generator mode, as I reported in a different issue.

[lelegard]

With one exception, according to ISO/IEC 13818-1:

In duplicate packets each byte of the original packet shall be duplicated, with the exception that in the program clock reference fields, if present, a valid value shall be encoded.

This mean that duplicates are never accidental. They must be generated in the network and explicitly
updated. I have never specifically searched for duplicate packets in live streams. So, I do not know if this is the case in practice.

[lars18th]

Hi,

I suggest to include a simple parameter --enforce-no-duplicates to overcome the problem of duplicates when we're sure that they don't exist in the stream. So when this flag is enabled, then all CC counters will be recomputed without any check.

You agree, @lelegard ?
Regards.

[lelegard]

Fixed in commit b53e6c7