Each live stream includes 2 parts - video and audio. They usually go hand-by-hand but sometimes they are un-synchronized, which means video or audio stream has delay comparing to its counterpart. This behavior was seen in some of MPEG-TS hardware encoders like Elemental and Digital Rapids as example.
Small delays are usually compensated by all player software but as far as the delay becomes significant - up to a few seconds - this becomes a problem which leads to playback failure in some players like VLC.
This issue is overcome by adding interleaving compensation. What it does is that it creates a buffer of incoming frames and sorts them for further output. This solves the described problem but introduces some delivery delay and resource overhead because buffering and sorting is done for all stream all the time. This operation is resource-consuming and brings latency into streaming process, as each frame is placed into the buffer and needs to be held at least until the next frame comes in.
This is why Nimble Streamer has this compensation disabled by default and you need to specifically enable it to make this work. As always, this is done via WMSPanel web control UI. You can enable it both for the entire server and for any specific application.
To make the compensation work, click on "Enable interleaving compensation" checkbox. This will show new fields to control parameters.
Min. delay is the parameter which specifies when Nimble needs to start buffering. The default value is 1000 ms which means that if the delay between video and audio is less than 1 second, then compensation will not be performed. As soon as the delay reaches this value, the data will be buffered and sorted. If the delay is changing over time - e.g. from 0.4 to 1.5 seconds - then compensation will be applied only when the delay value reached the "Min. delay" value.
If you set this value to 0 then your streams will be sorted all the time giving out monotonous sequences.
The default value of 1 second will be enough to skip the processing of small deviations that will play fine in existing players like VLC.
Max. delay specifies what is the maximum delay that needs to be handled and its default value is 3000 ms. This parameter is needed in case when the source encoder goes into some malfunction like when components' timestamp is invalid.
Max. queue items defines how many elements - e.g. frames - must be stored in a buffer. The deault value is 250 which stands for 5 seconds of 50fps stream. If the buffer is fully loaded then the oldest elements are sent out.
Small delays are usually compensated by all player software but as far as the delay becomes significant - up to a few seconds - this becomes a problem which leads to playback failure in some players like VLC.
This issue is overcome by adding interleaving compensation. What it does is that it creates a buffer of incoming frames and sorts them for further output. This solves the described problem but introduces some delivery delay and resource overhead because buffering and sorting is done for all stream all the time. This operation is resource-consuming and brings latency into streaming process, as each frame is placed into the buffer and needs to be held at least until the next frame comes in.
This is why Nimble Streamer has this compensation disabled by default and you need to specifically enable it to make this work. As always, this is done via WMSPanel web control UI. You can enable it both for the entire server and for any specific application.
To make the compensation work, click on "Enable interleaving compensation" checkbox. This will show new fields to control parameters.
 |
| Set interleaving compensation server-wide. |
 |
| Set interleaving compensation for specific application. |
Min. delay is the parameter which specifies when Nimble needs to start buffering. The default value is 1000 ms which means that if the delay between video and audio is less than 1 second, then compensation will not be performed. As soon as the delay reaches this value, the data will be buffered and sorted. If the delay is changing over time - e.g. from 0.4 to 1.5 seconds - then compensation will be applied only when the delay value reached the "Min. delay" value.
If you set this value to 0 then your streams will be sorted all the time giving out monotonous sequences.
The default value of 1 second will be enough to skip the processing of small deviations that will play fine in existing players like VLC.
Max. delay specifies what is the maximum delay that needs to be handled and its default value is 3000 ms. This parameter is needed in case when the source encoder goes into some malfunction like when components' timestamp is invalid.
Max. queue items defines how many elements - e.g. frames - must be stored in a buffer. The deault value is 250 which stands for 5 seconds of 50fps stream. If the buffer is fully loaded then the oldest elements are sent out.
The described approach can be used for a number of corner cases of live streams processing, while still having high performance and efficient resources usage.
Please also check Troubleshooting Live Transcoder article which describes other corner cases of Transcoder usage.
If you need any help on this feature set, feel free to contact us.
Troubleshooting
Please also check Troubleshooting Live Transcoder article which describes other corner cases of Transcoder usage.
If you need any help on this feature set, feel free to contact us.
