The health crisis and the multiplication of remote events explain in large part the strong demand for live broadcasts: conferences, masterclasses, and cultural or sporting events forced behind closed doors.
In designing the new Streamlive, we took into account the many use cases presented to us and made improvements accross the board.
Live streaming takes many forms: one can want to stream continuously for several hours or days or stream temporarily; the stream can be recorded or not; when a recording is made, a "replay" can be offered or not. Some broadcasts may be interrupted and resumed. Should multiple streams be created or only one? Should a single recording be made or several?
The maximum number of viewers who will be connected simultaneously to a Live is difficult to know in advance, as is the location of their connection. That's why it's essential to always use a CDN (Content Delivery Network) to anticipate extreme loads, distribute the stream around the world, and offer the fastest path between Streamlive servers and your audience.
A "Live" is often accompanied by a "chat". It is therefore important to reduce as much as possible the latency (the delay) between the live event and its display to the Internet user. With the new Streamlive, the latency is as low as 10 and 20 seconds depending on the characteristics of your stream.
When broadcasting to social networks and mobile devices, the image orientation is often vertical. So this is a new parameter for stream configuration.
In addition, there are various requirements for securing the broadcast, for example to make it only visible from a website, from a corporate network or by authorized users who paid to watch it.
Finally, it is important to have detailed analytics in real time, which go beyond the number of viewers connected: the evolution of the viewership over time, the playback quality, the origin of viewing, etc.
So what are you waiting for?
On the technical side
The new Streamlive dedicates a server to each new broadcast. This server is therefore turned on on demand and turned off after use. It is connected to the CDN in such a way as to accept the highest loads (simultaneous connections).
For a live broadcast intended for an internal network, it is possible to set up one or more cache servers that will limit the occupation on the company's Internet bandwidth. Thus, the stream will be pulled only once from the Streamlive platform (from the CDN), then it will be republished locally within the corporate network. It is also possible to set up a peer-to-peer internal network by configuring the video player to securely redistribute the data it already downloaded.
On the commercial side
For Streamlike customers, it is an option with a sliding scale of prices, depending on the volume of hours of activation of a Streamlive server. For example, a volume of 10 hours allows you to broadcast 8 live shows of one hour each preceded by 15' of tests. Or a continuous broadcast of 8 hours, with 1 hour of tests and a 1 hour provision in case of overflow.
You can track Streamlive activation time in the "statistics" menu and the "Streamlive platform" tab.
The volume of data transfer (the "bandwidth") is taken from the same "transit" pack as VOD, for simplicity and for faster access to the degression levels.
As always, the service is not interrupted when the subscribed amount is consumed, but an overrun will be charged.
To sum up
- Three streaming and recording modes
- 10-minute DVR (instant replay)
- Streaming via a CDN and a route optimizer
- Reduced latency
- Two possible device orientations
- Three security modes
- Real-time analytics
- Administration from the Streamlike console
- Can be integrated with StreamOut
- Caching on internal networks (via proxy -AKA eCDN- or peer-to-peer)
- Controllable through the Streamlike API
- Simple billing and sliding scale pricing