Data corruption with null packet deletion option

Context

Ubuntu 24.04.1 LTS with packages librist4 and librist-dev version 0.2.10+dfsg-2.

I use a simple local RIST transmission using the rist plugin of TSDuck (transport stream format). Since the transmission is local, the very same librist is used on sender and receiver side.

When null packet deletion is enabled on the sender side, the data are corrupted after a few thousands TS packets. Without null packet deletion, the transmission always remains correct.

Command lines

FYI, the sender and receiver commands are:

tsp -d -b 1,000,000 -I null -P regulate -O rist "rist://127.0.0.1:6666" --null-packet-deletion 
tsp -d -I rist "rist://@127.0.0.1:6666" -O drop

Usage of librist API

The sender command generates a transport stream of stuffing packets at 1 Mb/s and sends it to rist://127.0.0.1:6666. When the option --null-packet-deletion is specified, rist_sender_npd_enable() is called before rist_peer_create(). Chunks of contiguous TS packets are sent using rist_sender_data_write().

The receiver command reads TS packets from rist://127.0.0.1:6666 and drops them. Chunks of contiguous TS packets are received using rist_receiver_data_read2().

Errors

The receiver framework check the presence of 0x47 at the start of all TS packets. This is how the corruption is detected.

Here are two examples of error reporting, dumping what should be the start of a TS packet:

* Error: rist: synchronization lost after 11,038 packets, got 0x75 instead of 0x47
* Debug: rist: data at loss of synchronization:
    0000:  75 62 75 6E 74 75 00 00 83 CC 00 05 7B 9A 8A DA  ubuntu......{...
    0010:  52 49 53 54 83 AA 85 34 73 C2 D2 78 00 00 00 00  RIST...4s..x....
    0020:  77 84 B2 A6 52 49 53 54 83 AA 85 34 72 05 5F FB  w...RIST...4r._.
    0030:  00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF  ................
    0040:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................

* Error: rist: synchronization lost after 4,351 packets, got 0x00 instead of 0x47
* Debug: rist: data at loss of synchronization:
    0000:  00 00 00 00 00 00 00 00 81 CA 00 04 4F E5 5A 12  ............O.Z.
    0010:  01 08 76 6D 75 62 75 6E 74 75 00 00 82 CC 00 05  ..vmubuntu......
    0020:  4F E5 5A 12 52 49 53 54 83 AA 89 65 4C B3 73 E0  O.Z.RIST...eL.s.
    0030:  00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF  ................
    0040:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................

Note that the host name is "vmubuntu".

On the sender side, each rist_sender_data_write() is called with an integral number of TS packets (data size is a multiple of 188).

On the receiver size, the payload_len field of the struct rist_data_block is checked to be a multiple of 188 before analyzing the content. This check always passes, including when the stream is later found as corrupted. So, the data size does not appear corrupted, only the data content.