Skip to main content

Low latency Live Streaming

When creating a stream, you can choose either normal or low latency. By default, your stream will play with a 30-second delay. In low-latency mode and ideally, the delay of the live streaming service is about 10-15 seconds. But achieving this amount of delay requires settings on your server side.

On the other hand, the input frame of the content is gone out from the ArvanCloud live streaming service after 4.8 seconds. This does not mean that the delay in live streaming is limited to this amount, but there are other factors that affect the final number. Actually

The final amount of delay = (A) Content Sending Time + (B) Processing Time (4.8 seconds) + (C) Content Receiving Time to the Player + (D) Playback Time by the Player for the End User

In the following, we will fully examine how to reduce these 4 parameters.

Reducing Content Sending Time​

The important thing to note is that ArvanCloud's live broadcast service can provide 3 outputs of received content (depending on the user's choice and recognition) and it is usually recommended for live broadcast services to use all three outputs for three groups of the user:

  • Output with high bitrate and resolution for users with high internet speed and quality .
  • Output with medium bitrate and resolution for users with good internet quality and speed.
  • And finally, the output with low bitrate and resolution should be provided for users who do not have good internet quality and speed.

Therefore, there is no need to send multiple contents (this case causes a delay in receiving the content by ArvanCloud Live Streaming Service and may jeopardize its performance). Regarding delay reduction, there is an important recommendation:

The sent content should have the lowest bitrate possible to ensure the reduction of the delay in sending.

In addition, ArvanCloud's live streaming service takes the least amount of time to produce the required output.

Regarding the choice of bitrate, you should pay attention to the fact that the bitrate sent should not be lower than the expected bitrate in the output so as not to reduce the quality unintentionally.

Among other tips that will help you in reducing the time of sending content, the following can be mentioned:

  • Make sure you are using the CPU to encode the content. Using a graphic card creates an overhead of data conversion and exchange.
  • Select CPU Usage Preset as ultrafast and Tune as zerolatency.
  • In the x264 Options field, you can write the value bframe=0 crf=X. The value of X is a number from 1 to 20. A smaller number means higher quality and more CPU consumption. It is recommended to choose this value by trial and error. You can use the number 15 to start.
  • Among the factors involved in this stage is the use of a system with dedicated resources. This means that none of the resources involved (RAM, CPU, Internet) should be shared with other programs or systems.

The best result is achieved when you get the best output from this part according to the available resources and content, which can only be achieved by testing in different conditions.

Reducing Content Processing Time (4.8 Seconds)​

All the recommendations presented at this stage are to keep this amount constant and not to increase it unconsciously. This means that this amount is the minimum possible and will not be reduced. Among the influencing factors in it, is the expected output (proposed in the previous section) of the stream. If we set 3 outputs for the stream (when creating it), naturally, the frame preparation time will be long. So when it comes to reducing latency, we recommend using only one output instead of all three suggested live streams.

Reducing Content Receiving Time by the Player​

Among the influential factors in this stage, we can mention the selected output and the quality of the end user's Internet when receiving the output. Therefore, it is recommended to be more obsessive in choosing the output.

Reducing The Playback Time by Player for The End User​

The manifests provided by ArvanCloud's live broadcast service include 3 chunks of 6 seconds in normal mode, and the length of these chunks in low latency mode is two seconds. To create a continuous and integrated playback experience for the end user, common players take advantage of this opportunity while playing the current chunks and start receiving the next chunks so that they are ready to play when it is their turn.

In general, the player has the opportunity to download the next chunk while the last chunk is played, but according to its default settings, every player starts from the last few chunks the first time it starts streaming. This process can cause a delay of several seconds in the broadcast. What can be done at this point is to set the player to always start with the last chunk so that the delay in playback is as low as possible. The thing that should be considered in this regard is that the stability of the broadcast is inversely proportional to its being Realtime, and reducing the delay will reduce the continuous, seamless, and lag-free playback. Therefore, finding the best chunk to start playing, requires checking different settings and estimating and comparing their results.

In general, for the player and during playback, to be compatible with the Low Latency structure, the player should be set to read the last Chunk in the Manifest as much as possible, but under certain conditions.

In the LL structure, the Manifest is usually considered small and the length of the chunks is considered shorter than the usual standard. For example, in the ArvanCloud structure, we consider a Manifest with three chunks, the length of each chunk is 2 seconds, which eventually becomes six seconds long.

On the user's side, the Player operates in this 6-second interval, that is, if the user is anywhere in this 6-second interval, the player will play normally, but if it goes out of this interval and the time difference with what it receives is more than 6 seconds. So, here it starts playing from the last chunk. For this reason, it is possible that two devices are next to each other and one of them has an internet outage at the moment and this outage lasts one or two seconds. After the device is connected to the Internet, the user sees the desired stream with a difference of two seconds compared to the other device or user and does not receive the last chunk because it is within 6 seconds or the length of the Manifest.

In general, setting the Player to always read the last chunk in any situation, even if it is within the range and length of the Manifest, is not a correct and standard practice, because, in unstable Internet conditions, it causes users to lose and not see the frame or images.

Another thing worth mentioning is that using MPEG-DASH has a better result in syncing the broadcast between multiple users, therefore, it is recommended to use MPEG-DASH for Android users and HLS for iOS users.