How to configure error correction and calculate bandwidth on the MPX Node
Scope:
This document covers how to configure error correction on the Omnia MPX Node Encoder and calculate the total amount of bandwidth required to use it.
Configure Error Correction
MicroMPX streams over UDP, which is susceptible to packet loss on busy or unstable networks. It contains multiple mechanisms to ensure stable streaming even when packet loss occurs. Forward Error Correction is implemented in the MPX Node Encoder. MPX Node Encoder has two controls to adjust error correction. (The Decoder is a follower, and has no error correction settings of its own, only a fixed receive buffer).
How to set error correction controls
Here's what a typical setup looks like:
What the settings above say is: “Every 64 packets, send 8 extra packets as overhead.”. For each original 64packets, 72 actual packets are sent. As long as at least 64 of the resulting 72 packets arrive, the decoder can reconstruct all the missing packets.
The resulting bitrate is slightly higher than the configured bitrate. For example, when the bitrate is set to 320 kbit/s, and 64/8 is used as recovery settings, the resulting bitrate is 320 + 320 * 8/64 = 360 kbit/s.
Network dropouts typically occur in bursts, so typically you'll see a number of subsequent packets getting dropped. This means that in the end, it doesn't really make a lot of difference for how resilient the signal is against packet drops whether you set it to 64/8 or for example 32/8 or 128/8. You might think that 128/16 is similar to 64/8, but it's actually (almost) twice as powerful, at the same bitrate (320 + 320 * 16/128 is also 360).
You also might wonder why there are two settings ("Size/Delay" and "Overhead" - set to 64/8 in the example above) and not just one (8). That's because the first value "Size/Delay" determines how much time there is between blocks of recovery packets. MicroMPX sends about 94 packets per second, not counting the recovery packets, so when you use 64/8 the latency of the decoder must be at least about 0.7 seconds. For 128/16 it needs to be 1.4 seconds. You should set the value a bit higher than this to account for small differences in speeds and the time it may take to send FEC packets; using 1 and 2 seconds in these example cases is definitely safe.
As an example, let’s say that according to the error logs, the biggest drop that has been reported was a drop of 5 packets. In that case, you’ll want to make sure that all the drops of up to and including 5 packets will be recovered, so the error correction “Overhead” must be set to at least 5 packets. You might want to set it a bit higher to also recover slightly longer dropouts.
If you want to keep your delay at at most 1 second, you can set "Size/Delay” to around 64 packets. If you don’t mind having more latency, you can set that value higher without really affecting recovery, as described above.
The "Keyframe interval" determines how often a keyframe packet is sent. If the connection is really lost, or if the decoder switches to a different stream or is initially started, playback can only (re)start on keyframes. If a packet is lost, playback will halt until the next keyframe is received. Setting the time between keyframes lower will therefore result in shorter dropouts if a dropout occurs. Setting "Keyframe interval" lower will leave slightly fewer bits for data, but it doesn't really have a big impact, so you can safely set it to 0.5 seconds for example.
Finally, "Limit Rate Below" controls how fast packets can be sent through the network. You should normally just leave this at the default setting. All recovery packets in a block are generated at once. If the number of recovery packets is high, this can lead to many packets being sent to the network at high speed. This could in itself cause packet loss. So, without rate limiting, adding a lot of recovery packets would actually make the connection less reliable. Because of this, it's usually best to leave this setting slightly higher than the theoretical value calculated above (the bitrate multiplied by the error correction factor), and always lower than the maximum network capacity available).
Error correction's effect on bandwidth
Utilizing the advanced error correction found in the Omnia MPX Node requires additional bandwidth. The amount of additional bandwidth needed by error correction is a percentage of the bitrate in use. Adjusting "Error Correction size/delay" and "Error Correction Overhead" dynamically affects this percentage. Below is a calculator to determine how much bandwidth is required to pass a stream, and how much data a stream consumes over time. For more information, refer to the user manual.
| MPX Node Bandwith Calculator | |
| Encoder Bitrate | |
| Error Correction Span | |
| Error Correction Overhead | |
| Bandwidth required for transmission | ... |
| Data utilized (per MPX Node Decoder) | |
| 1 day | ... |
| 7 days | ... |
| 30 days | ... |
Let us know how we can help
If you have further questions on this topic or have ideas about how we can improve this document, please contact us.
