This article mainly describes the live video delay you can experience with h264 cameras. If you have an MJPEG camera, then the delay is given only by the frame rate of the camera and the sum of network delays between your camera, Angelcam Cloud, and the viewer. The information below does not apply to MJPEG cameras.

As you’ve probably noticed, when watching live video from your cameras in My Angelcam or using the Angelcam mobile application, the video is being displayed with some delay. This article will help you understand where this delay comes from and how you can minimize it if needed. It isn’t a simple topic, so ensure you have enough time to read and understand all this. Make yourself a coffee or another favorite beverage, and let’s start!

This is the delay between opening the Angelcam app and seeing the first video frame. Two situations can happen here:

The first situation usually happens when no one else is watching the stream from your camera using the Angelcam app, and the Angelcam Cloud Recording is not enabled on the camera. Simply, Angelcam does not pull the video from your cameras unless the video is needed. This feature can save you a lot of data transfer that your local ISP could charge for. But it imposes a small delay (depending on the settings) when the connection to your camera must be created first.

The second situation happens when the video stream from your camera is already being consumed by the Angelcam Cloud Recording or another viewer watching the same camera.

Angelcam offers two modes for your cameras — standard and low latency. The video will be delivered in the standard mode using the HLS protocol. This protocol is widely supported, and you should be able to play your video in pretty much any modern web browser and the Angelcam mobile app. The disadvantage of this protocol is that Angelcam servers need to buffer a certain amount of video before it can be delivered to the viewer. This is especially visible when the Angelcam Cloud is creating a new connection to your camera. The video buffer is empty when the connection is created and needs to be filled before the video can be sent over to the viewer. This results in an approximately 15 seconds long black screen that can be seen when the Angelcam Cloud must create a new connection to your camera. If the connection to your camera is already up and running (e.g., because of cloud recording), the HLS protocol can almost instantly deliver the video to you.

In the low latency mode, the video will be delivered using a fragmented MP4. This protocol offers a significant improvement when the connection to your camera must be created, but the protocol is not as widely supported as HLS. Currently, you won’t be able to use fragmented MP4 in Safari on any platform and in any web browser under iOS. Unlike HLS, this protocol requires buffering only a small amount of video from one key-frame to another. This results in fast start-up times when Angelcam Cloud is not connected to your camera and the same start-up times when the connection has already been established. The exact delay depends on the distance between key-frames, which can usually be controlled in your camera settings. Most cameras call this parameter GoP size. It is usually expressed in the number of frames between two key-frames (including the first key-frame). Lowering the GoP size will also lower the video start-up delay and increase the bandwidth requirements due to the increased number of key-frames. A reasonable key-frame interval for live streams is around 2 seconds, so if your frame rate is 30 frames per second, the GoP size would be 60.

Another source of delay we haven’t discussed yet is network delay. However, network delay is usually only a small fraction of the delays described above; therefore, it can be considered negligible for the video start up.

As discussed above, Angelcam offers two modes for your cameras — standard and low latency — with HLS and fragmented MP4 protocols, respectively. These protocols greatly affect the video start-up time and the delay until a real-world event can be observed in the corresponding video stream. The former has already been discussed above. Let’s focus on the delay of real-world events now.

In the standard mode, when the HLS protocol is being used, the delay of real-world events is mainly given by the size of the video buffer (discussed above). For reliable operation of the HLS protocol, the video buffer needs to contain at least 3 video segments, and each is 6 seconds long. Moreover, we need to collect 6 seconds of video before a new segment can be added to the buffer, so there is always one “in progress” video segment — a segment being constructed. A video player usually starts playback from the beginning of the video buffer, although it may vary depending on the player's implementation. This means that the delay of real-world events will usually be between 18 and 24 seconds + network delay. The network delay may add a few seconds because video players usually try downloading at least one or two video segments before they start with the playback. So, the delay of real-world events in the HLS video is usually between 20 and 30 seconds.

In the low-latency mode, the video buffer is significantly smaller. The buffer contains only video from one key-frame to another, and once collected, the chunk is immediately sent over to the player. Thus, the delay of real-world events depends mostly on the GoP size settings in your camera. On average, you can expect a delay of half the distance between key-frames + a small network delay. The maximum delay would be the full distance between key-frames + the network delay.

If you need to minimize the start-up time and the delay of real-world events, try using the low-latency mode and make sure that the distance between key-frames (see your camera settings) is around two seconds. If you care more about browser compatibility, disable the low-latency mode and ensure that the distance between key-frames is no more than six seconds.

Please note that if you use your camera for broadcasting, the broadcasting player will always use the HLS protocol even if you enable the low-latency mode. This will ensure maximum compatibility for your viewers.

😇 We are here to help

Just say hello@angelcam.com or check out Angelcam Community to connect with other users sharing their own experiences and insight into various security topics.