When configuring an SRT stream, you will see a drop down for “Null Packets”. Here is some helpful information on why the V410 includes this option in SRT settings, especially when setting the Video Parameters to CBR (Constant Bit Rate)
Why isn’t setting video encoding to CBR enough to smooth out my stream from spikes and dips in bandwidth?
Your video may be encoded as CBR, but the stream can still leave the encoder in uneven bursts because some frames are larger than others. Null packet insertion adds harmless filler packets to smooth the stream into a steadier pipe. The receiver ignores those filler packets, but the network and decoder see a more consistent transport rate.
Why does this matter with SRT or TS-Over UDP?
SRT is the transport layer. It is designed to carry live video over unpredictable networks and recover from jitter, delay, and packet loss. The SRT documentation says SRT’s job is to recreate the timing characteristics of the live signal at the receiver and maintain constant end-to-end latency. It also says live streaming data should be produced at the same speed it will be consumed by the player.
That is why timing matters. If the encoder sends uneven bursts, SRT can still transport them, but the sender buffer, receiver buffer, retransmission timing, and downstream decoder all have to deal with more variation. A steadier MPEG-TS rate gives SRT a more predictable stream to pace.
What are Null Packets then?
Most SRT contribution feeds carry MPEG-TS over SRT. MPEG-TS packets are 188 bytes, and SRT commonly sends them in 1316-byte chunks, which equals seven MPEG-TS packets per SRT payload. Haivision’s SRT live-streaming guidance specifically calls out 1316 bytes as a good transport unit size for MPEG-TS over SRT.
A null packet is an MPEG-TS packet that carries no real video, audio, or metadata. It is filler. In MPEG-TS, null packets use PID 0x1FFF. Receivers are supposed to discard them. Their purpose is to keep the transport stream bitrate steady when there is not enough real payload to fill the target rate.
What is x1.2 and x1.5 for exactly?
| Setting | Meaning | Example with 10 Mbps real stream |
|---|---|---|
| Off | Send only real audio/video/data packets | ~10 Mbps, more variable |
| x1.2 | Pad transport rate to about 120% of content rate | ~12 Mbps total |
| x1.5 | Pad transport rate to about 150% of content rate | ~15 Mbps total |
The receiver should see a steadier total MPEG-TS/SRT input rate, but the extra bitrate is not improving image quality. It is overhead.
Want more technical methods on what it does?
Video is naturally uneven, even when labeled “CBR.” An I-frame may be large, P/B frames are smaller, audio is steady, metadata is occasional, and scene complexity changes. The SRT docs describe exactly this issue: not all frames are the same size, yet live transmission must preserve the average timing of the stream. Null packets help by filling the low points.
Without padding:
With padding:
That steadier output can help:
- receivers that expect a true CBR MPEG-TS input;
- broadcast gear that measures transport stream bitrate stability;
- decoders sensitive to bursty input;
- monitoring systems that flag bitrate dips;
- SRT links where smoother packet pacing is preferred.
When do I choose to use x1.2 or x1.5?
Use x1.2 as the normal recommendation. It gives the stream breathing room without wasting too much bandwidth.
Use x1.5 when the receiving platform is strict about CBR, the content has large bitrate swings, or the customer is seeing bitrate-dip alarms, decoder instability, or SRT input-health warnings.
Do not use x1.5 on constrained networks unless there is enough upstream bandwidth. SRT may recover packet loss, but if you intentionally raise a 10 Mbps stream to 15 Mbps on a 12 Mbps uplink, you will make the stream worse.
Wrap Up:
Null packet insertion makes the SRT/MPEG-TS output more constant by adding discardable filler packets. This is useful when a receiver or broadcast workflow expects a steadier CBR transport stream. The x1.2 setting pads the stream to roughly 120% of the encoded content rate, while x1.5 pads it to roughly 150%. The tradeoff is higher network bandwidth usage; the added packets do not improve picture quality and are discarded by the receiver.