Our company keeps improving new real-time low latency protocol called SLDP. It provides quick start, sub-second delay and real-time ABR for live streaming delivery. You can find protocol overview in this page and some basic setup and usage described in this article.
One of the features of SLDP is an ability to keep up with live stream without delays regardless of environment glitches. Let's take a look at this capability more closely.
Let's say you have a live stream which you'd like to take a close look real-time, e.g. you're watching a game or following some bid at auction.
At some point, an environment glitch may appear on a viewer side, e.g. CPU stuck with decoding or some network delay happened. In this case the picture in a player will freeze, waiting to proceed. Meanwhile stream's frames will still be arriving without being displayed.
There are 2 possible scenarios here:
The first option is the default one. To handle the second option, SLDP player supports latency_tolerance parameter. It's a latency retention expressed in milliseconds. When initial delay has increased by more than the specified value, it forces the player to reestablish the initial latency as it becomes possible.
It's important to understand that latency retention has its cost, the player skips a part of stream to preserve latency. The rough analogy can be TV broadcast, when corrupted image is displayed but the whole stream is not delayed.
So you can use it if your streaming use cases require that type of behavior.
One of the features of SLDP is an ability to keep up with live stream without delays regardless of environment glitches. Let's take a look at this capability more closely.
Let's say you have a live stream which you'd like to take a close look real-time, e.g. you're watching a game or following some bid at auction.
At some point, an environment glitch may appear on a viewer side, e.g. CPU stuck with decoding or some network delay happened. In this case the picture in a player will freeze, waiting to proceed. Meanwhile stream's frames will still be arriving without being displayed.
There are 2 possible scenarios here:
- Resume playback from the point where the glitch has started.
- Skip the playback to initial latency.
The first option is the default one. To handle the second option, SLDP player supports latency_tolerance parameter. It's a latency retention expressed in milliseconds. When initial delay has increased by more than the specified value, it forces the player to reestablish the initial latency as it becomes possible.
It's important to understand that latency retention has its cost, the player skips a part of stream to preserve latency. The rough analogy can be TV broadcast, when corrupted image is displayed but the whole stream is not delayed.
So you can use it if your streaming use cases require that type of behavior.
You can see this and other parameters of our HTML5 player on this player page.
From the media server setup perspective SLDP is just another output protocol from the list of supported ones, which you can see on our live streaming digest page. So feel free to try it in action with our HTML5 web player.
Take a look at the answers for frequent questions to improve your SLDP usage and visit SLDP website and contact us in case of any questions.
From the media server setup perspective SLDP is just another output protocol from the list of supported ones, which you can see on our live streaming digest page. So feel free to try it in action with our HTML5 web player.
Take a look at the answers for frequent questions to improve your SLDP usage and visit SLDP website and contact us in case of any questions.
No comments:
Post a Comment
If you face any specific issue or want to ask some question to our team,
PLEASE USE OUR HELPDESK
This will give much faster and precise response.
Thank you.
Note: Only a member of this blog may post a comment.