GstNetBalancer - About NetBalancer Plugin

From RidgeRun Developer Wiki



  Index Next: Getting Started






Netbalancer use case

Bandwidth requirements for network streaming are a vital part of most multimedia applications, and it plays a critical role in wireless streaming applications such as wifi or radio links. For most wireless streaming applications, going beyond the limited bandwidth causes artifacts in the video content such as green and blocky regions or ghosting effects like the ones shown in the following video.


When the wireless link is known to support the video streaming requirements, then these artifacts are typically caused by an incorrect distribution of the data packets when streamed over the link. This type of problem is what GstNetBalancer has been developed for.

An ideal use case for the netbalancer element happens when there are spikes of data transmitted in a very small time frame; meaning that the network load is not constant, so it is heavily stressed for a short time and idle the rest of the time.

A real world example of this is the transmission of compressed video where I-frames are significantly larger so they periodically stress the network and these frames don't need to be immediately available on the receiver since the stream works at a fixed framerate. The netbalancer can space out the packets that make up the I-frames and send them at a pace that alleviates the network and keeps the framerate requirements.

Netbalancer fundamentals

In order to get the out most of a network connection, the netbalancer element distributes data packets in time so that the rate of transmission is as evenly distributed in time as possible. As a result, the netbalancer can cause the bandwidth curve to diminish the frequency/amplitude of peaks and reduce significantly the amount of data sent per millisecond hence reducing the maximum bandwidth required. This is achieved by introducing dynamic delays between packets; the element keeps track of the amount of data that has been transmitted in a limited time frame. In case a new package wants to be sent but the data cap for that time frame has already been reached, then the packets are delayed until a new time window starts. This ensures that the data transmission is always under a specified bandwidth.

The netbalancer does not modify the contents of any of the packets or the way they are sent. The characteristics of the packets remain the same; the only thing that varies is the rate at which these packets enter and exit the element pads.

The netbalancer then does not replace any of the elements in a pipeline; it is not intended for packaging data nor send it over a network. A netbalancer element is usually added at the end of the streaming pipeline; just before a sink element, but can be added anywhere wherever the packet rate wants to be controlled.

The following image represents the netbalancer theoretical functionality:

Figure 1. netbalancer behavior representation



  Index Next: Getting Started