[Q] SPTS from a MPTS with constant packet size

[MaxMuc81]

Hello,
I have tried to extract one channel from a MPTS transport stream. It works, but the new transport stram has a dynamic packet size with small Packages. (e. g. 188 instead von 1316). With the option --stuffing I get the original packet size of the MPTS, because the SPTS transport stream is filled with 0 bits and the original bitrate of the MPTS.
Is it possible with ts duck to get a SPTS with no 0 bits and a constant packet size of e. g. 1316?

[lelegard]

the new transport stram has a dynamic packet size with small Packages. (e. g. 188 instead von 1316)

By specification, all transport streams have and have always had a fixed packet size : 188 bytes.

You probably refer to UDP transport where the convention (not a requirement) is to group 7 TS packets (7x188=1316) per UDP datagram because this is the highest number of TS packets for which a UDP datagram remains below the old Ethernet MTU, 1500 bytes. Other forms of TS transports use other forms of TS packet clustering, or no clustering at all (files, broadcast).

So, I assume that you use ip both as input and output plugin.

With the zap plugin, as well as any other plugin which removes TS packets, the output plugin typically receives smaller chunks of TS packets. By default, the ip output plugin sends TS packets as soon as it receives them. Therefore, when some plugin removed packets, the UDP datagrams can be sent with less than 7 TS packets. This is legal and it should work with any valid receiver. However, this is not optimal. If you want to enforce 7 packets per output UDP datagram (and consequently force the output plugin to wait for that number of outgoing packets), use option --enforce-burst (RTFM for more details).

With the option --stuffing I get the original packet size of the MPTS, because the SPTS transport stream is filled with 0 bits and the original bitrate of the MPTS.

With option --stuffing, the TS packets to remove are kept in the TS but replaced with so-called "null packets". Thus, the output plugin receives the same number of TS packets as input is producing, at the same rate, and the outgoing UDP datagrams are usually full (7 TS packets). However, this is very inefficient in terms of network bandwidth.

Also note that the stuffing packets are NOT filled with 0 bits. Null packets are sent on reserved PID 0x1FFF and their payload is filled with 0xFF bytes.