Nimble Streamer was initially designed to cover two basic cases: serve progressive download and re-stream HTTP media protocols, having HLS and Smooth protocols to support first.
Effective HLS and Smooth re-streaming requires effective caching. That's because edge servers may be used in a distributed network for quick and cost-effective delivery for end-users. You may have single Wowza origin to make perfect transcoding and transmuxing and then have Nimble servers to take streams from Wowza, cache them and distribute to users in some geographical or network area.
The more effective cache Nimble has, the less expensive is the cost of stream delivery to multiple viewers. There are several basic caching features that help making it better.
For live streaming, each chunk is primarily stored in RAM. This allows a very fast access to the cached content. You can control cache size by using max_cache_size parameter in Nimble config.
Each chunk is stored some limited period of time. Currently it's 30 seconds by default. This time is counted since the last access to the chunk. So the most popular chunks will be stored in RAM allowing quick and easy access.
If you use HLS or Smooth for live streaming delivery, the Streamer handles it properly too. If thousands of viewers are requesting the same new chunk from the stream playlist, Nimble requests this chunk just once and any viewer that is asking for the same, will just get it right after it is downloaded from the origin.
It’s important to notice that caching for HLS re-streaming is not available when HTTP Origin mode is enabled. In HTTP origin mode, Nimble Streamer works as a pass-through, fetching content directly from the Origin server without caching it at Edge server.
Effective HLS and Smooth re-streaming requires effective caching. That's because edge servers may be used in a distributed network for quick and cost-effective delivery for end-users. You may have single Wowza origin to make perfect transcoding and transmuxing and then have Nimble servers to take streams from Wowza, cache them and distribute to users in some geographical or network area.
The more effective cache Nimble has, the less expensive is the cost of stream delivery to multiple viewers. There are several basic caching features that help making it better.
For live streaming, each chunk is primarily stored in RAM. This allows a very fast access to the cached content. You can control cache size by using max_cache_size parameter in Nimble config.
Each chunk is stored some limited period of time. Currently it's 30 seconds by default. This time is counted since the last access to the chunk. So the most popular chunks will be stored in RAM allowing quick and easy access.
If you use HLS or Smooth for live streaming delivery, the Streamer handles it properly too. If thousands of viewers are requesting the same new chunk from the stream playlist, Nimble requests this chunk just once and any viewer that is asking for the same, will just get it right after it is downloaded from the origin.
It’s important to notice that caching for HLS re-streaming is not available when HTTP Origin mode is enabled. In HTTP origin mode, Nimble Streamer works as a pass-through, fetching content directly from the Origin server without caching it at Edge server.
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.