HLS inputs on-demand¶

Contents¶

What are on-demand streams for?¶

If the stream is set to On-demand, it will only turn on when it receives a request from the user. If the user has lost the need for viewing, or the source from which the stream is broadcasted has stopped its work for some reason, the stream will automatically turn off after a certain time (timeout). On-demand is mainly needed to save resources (primarily traffic). This solution is well suited in situations where you have a large number of streams, but you do not need them to work simultaneously and continuously.

Read more about setting up On-demand streams here.

Problems with on-demand streams¶

The peculiarity of segmented protocols in On-demand is that when using them, the media player's buffer must be accumulated before the start of video playback (initial loading of at least 3 video segments), which takes a certain amount of time. Although parameters such as specific communication protocol, GOP size, segment length can affect the buffer accumulation time, this process and the associated delay are inevitable.

Problems with HLS protocol¶

HLS is a segmented protocol, so it takes a certain amount of time to accumulate a buffer.
In Flussonic Media Server, a check for determining the liveness of a source is implemented. Flussonic (restreamer), while connected to the HLS source, remembers the last seen segment and waits for the next one to appear. Flussonic will not start playing until it appears. This introduces additional playback delay.

Note

In case we receive an unknown (non-Flussonic) HLS source and relay it, without this check there is no other way to know whether the source is online or not. The absence of this check can lead to a infinite playback loop of the last read segments if the source goes offline at some point. Flussonic cannot trust a third-party source (even if it provides the required data), because it is impossible to determine what this source is.

The combination of all these factors will lead to the fact that you will face the problem of a stream's long start time.

How to fix it?¶

We have a solution for both of these problems — our proprietary M4F protocol. Its use removes the need to check the source (this protocol ensures that restreamer does not load already existing segments a second time, and source will reset the playlist if frames are missing on it), it also supports prepush (fast filling of media player's buffer) and provides information about archive of the source (or several sources at the same time), makes it possible to proxy the archive . As a result, both reasons for this delay are resolved. M4F is an internal Flussonic protocol, therefore, its use is possible only if Flussonic Media Server is both a source and a restreamer. Learn more about the M4F protocol.

Note

If your primary goal is On-demand streams and their output via HLS protocol, we strongly recommend you to contact your supplier with a request to install a Flussonic Media Server, and use the M4F protocol to connect between them. Eventually, you will get a well-synchronized configuration and solve the problems associated with long stream startups.