Recently, we added a new output mode to our encoder, “Null Packet Deletion.” But for many years, we have had a mode where null packets can be disabled. So why create a second mode to do what appears to be the same thing? As usual, the devil is in the details and there is a subtle difference between disabling null packets vs deleting null packets.
The History of Null Packets
First, let’s have a brief history lesson in MPEGTS. When TS packets were first put inside UDP packets, seven TS packets per UDP packet was chosen. There are a lot of devices that mandate seven TS packets per UDP packet and are unable to receive anything else.
Historically, TS streams were kept at a constant bitrate (to fit a radiofrequency channel, such as on satellite) by inserting null packets, packets containing no data but put there to maintain a constant bitrate. But in the internet era it was considered wasteful to transmit such null packets, so various products started allowing null packets to be disabled, known as a variable bitrate (VBR) mux (this needs to be distinguished from VBR encoding). Most (but not all) products stuck to the seven TS packets per UDP packet rule.
Many Flavours of Receivers
There are various flavours of receiver out there from a mux perspective:
- Mandates CBR mux, seven TS packets per UDP packet standard
- Accepts VBR mux but mandates seven TS packets per UDP
- Accepts VBR mux with 1-7 TS packets per UDP packet
VBR mux is valuable in the internet era: it reduces traffic in most cases by not sending wasteful null packets. In addition, when using packet retransmission protocols such as SRT, valuable retransmission attempts are not wasted on recovering null packets that will never be used.
Null packet deletion serves a different purpose. It removes null packets from the output stream so that the VBR stream has a variable number of TS packets per UDP packet.
Why Use Null Packet Deletion
So why would we want null packet deletion per output? There are several reasons:
- Per output null packet removal
- We might need to send to destinations that mandate a CBR Mux
- At the same time, we might want to send to other devices that accept a VBR mux with variable numbers of TS packets
- Maintaining PCR accuracy
The most important use case for null packet deletion is to maintain PCR accuracy. The main issue with mandating seven TS packets for a VBR mux is that it creates substantial PCR accuracy errors. This is because the TS packet containing the PCR is not transmitted at the right time, because six other TS packets are needed. The output of the encoder has to wait for these packets.
In null packet deletion mode, the TS packet is transmitted at exactly the right time, meaning there is no PCR accuracy issue.
The above diagram represents the worst-case wait time in different modes before the encoder can output a UDP packet (which occurs when the PCR packet is followed by six null packets) . At low bitrates, such as 1Mbit/s, the packet gap between TS packets is around 1 ms. The diagram shows the same UDP packet being transmitted but with differing numbers of PCR/nulls/data packets, depending on the setting used.
Null Packets Enabled – PCR is accurate because the null packets are present to keep the overall packet duration the same.
Null Packets Deleted – The PCR is accurate because the PCR packet is transmitted alone and at the right time.
Null Packets Disabled – The PCR is inaccurate as the output must wait for six other TS data packets, which can take as long as 20ms or longer to arrive.
Note that most TS analysers following TS 101 290 expect a CBR stream to perform correct PCR analysis. This explanation is also a bit of a simplification and doesn’t follow the traditional definition of PCR accuracy; it’s actually the processes in the receiver using the PCR that will suffer from the inaccuracy.
We can show below with two outputs, one with null packets enabled and one with null packets disabled, that packets are transmitted at exactly the same time:
We’ll talk about in the future why PCR accuracy plays a key part in synchronised output of streams.
Learn more about our low-latency encoders and decoders.
