GstNetBalancer/About NetBalancer Plugin: Difference between revisions
mNo edit summary |
No edit summary |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
{{GstNetBalancer/Head|previous=|next=Getting Started}} | {{GstNetBalancer/Head|previous=|next=Getting Started}} | ||
</noinclude> | </noinclude> | ||
{{DISPLAYTITLE:GstNetBalancer - About NetBalancer Plugin|noerror}} | |||
== Netbalancer use case == | == 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. | 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. | ||
<br> | |||
<br> | |||
<center> | <center> | ||
<embedvideo service="youtube">https://www.youtube.com/watch?v=Uw3mABdCOzQ</embedvideo> | <embedvideo service="youtube">https://www.youtube.com/watch?v=Uw3mABdCOzQ</embedvideo> | ||
</center> | </center> | ||
<br> | |||
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. | 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. | 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 | 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 == | == 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 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. | 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 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. | ||
| Line 25: | Line 28: | ||
The following image represents the netbalancer theoretical functionality: | The following image represents the netbalancer theoretical functionality: | ||
<br> | |||
[[File:GstNetbalancerRepresntation.png|center|frame|Figure 1. netbalancer | <br> | ||
[[File:GstNetbalancerRepresntation.png|center|frame|Figure 1. netbalancer behavior representation]] | |||
<noinclude> | <noinclude> | ||
{{GstNetBalancer/Foot||Getting Started}} | {{GstNetBalancer/Foot||Getting Started}} | ||
</noinclude> | </noinclude> | ||
Latest revision as of 15:12, 27 January 2023
| GstNetBalancer A GStreamer Network Balancer Element |
|---|
 |
| About NetBalancer Plugin |
| Getting Started |
| User Guide |
| Examples |
| Contact Us |
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:
