TsOutputSettings.flushPartialPackets property

Send each chunk’s leftover TS packets immediately instead of holding them back until there are enough to fill a whole 7 × 188 = 1316-byte payload.

By default an output only ever hands the socket full 1316-byte payloads, so the last few packets of a chunk wait for the next one — and on a stream with a low byte rate, waiting for 1316 bytes takes a while. On audio-only output at 128 kbps it is about 70 ms, whatever TsOutputSettings.audioFramesPerPes is set to, because the wait is for bytes and not for frames. Setting this to true removes that delay: the tail goes out at the end of every chunk as a shorter payload, still a whole number of 188-byte TS packets. The cost is the extra per-payload headers (under 1% of bandwidth) and payloads that are not all the same size, which a receiver expecting exactly 1316 bytes may not like.

Worth setting on a low-bitrate or audio-only output where latency matters; there is little to gain on a stream with real video bitrate, where 1316 bytes arrive in a millisecond or two anyway.

Only valid with the simple encoder — the broadcast encoder has already paced the stream to a constant rate, so there is nothing waiting, and configuring both is rejected. Has no effect on fileTs, which does not queue. Defaults to false.

Signature: