# Frame buffering

In order to ensure smooth video playback and preserve as much system resources as possible, LightAct carefully manages how many frames of a video file it keeps in its memory.

{% hint style="info" %}
**Good to know**: we use word buffering but some users prefer the word caching. It's essentially the same thing.
{% endhint %}

<div align="left"><figure><img src="https://3312042618-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9sVaJpWJhPbmscipukhh%2Fuploads%2FEHxCuTs9wXhnLFIKpNKI%2Fimage.png?alt=media&#x26;token=8b58185c-4767-4167-9788-80d651c46b2b" alt=""><figcaption></figcaption></figure></div>

These settings are configured in the properties of each Timeline separately. There you will find a **Video Playback** collapsible section with properties related to video playback.

* **Video Buffer**: This determines how many frames LightAct will attempt to keep in an internal buffer while playing a video asset.
* **Video Preload Time**: This specifies how many seconds before the playhead reaches the beginning of a layer containing a Play Video node, LightAct will load the frames into its *Video Buffer*.
* **Always Ready Buffer**: Timelines are not always played back in a linear fashion from start to finish. Sometimes the playhead jumps directly onto a video layer. This means LightAct keeps a certain portion of the *Video Buffer* in its memory at all times. This buffer is called the *Always Ready Buffer*.

### How does video frame buffering work?

<figure><img src="https://3312042618-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9sVaJpWJhPbmscipukhh%2Fuploads%2FRkhVECGsC2HggAyRypyg%2Fimage.png?alt=media&#x26;token=4d43f0eb-f0af-4c74-b5c7-181d346cbc4a" alt=""><figcaption><p>You can monitor the status of all Play Video nodes in the Performance window</p></figcaption></figure>

In this situation, we see that:

* **Video buffer** = 20 frames
* **Video preload time** = 5 seconds
* **Always ready buffer** = 50% of *Video buffer* = 10 frames

{% hint style="info" %}
**Good to know**: if you open *Performance* window, you'll see there is a Video playback collapsible section where you can monitor the status of all *Play Video* nodes in the project.
{% endhint %}

The playhead is positioned 5 seconds and 1 frame before the beginning of the video layer (cameraFeedCentraText) which is more than the 5 seconds we specified as the *Video preload time*. Therefore, the *Play Video* node has only 10 frames loaded in the memory which is 50% (*Always ready buffer*) of 20 (*Video buffer*).

<figure><img src="https://3312042618-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9sVaJpWJhPbmscipukhh%2Fuploads%2FuT68c1skBUd6BZgb3ZfZ%2Fimage.png?alt=media&#x26;token=bf0f1824-65ab-4508-a006-fc12404fbe07" alt=""><figcaption></figcaption></figure>

The moment the playhead reaches 5 second mark, *Play Video* node loads all the frames into its buffer (19 in the case above).

{% hint style="info" %}
**Good to know**: if you have problems with video playback performance, you might want to increase the Video buffer size to, say, 32 and Video preload time to, say, 20.
{% endhint %}

{% hint style="info" %}
**Good to know**: to analyze performance issues, watch *Missed frame* indicator in the *Performance* window and try to understand where the issue is.
{% endhint %}

{% hint style="info" %}
**Good to know**: for highly interactive timelines, where the playhead is jumping back and forth a lot, you might want to increase *Always ready buffer*.
{% endhint %}

#### Graphs in Play Video node

If you want to dive deeper into the stats of an individual **Play Video** node, you have to double click on the *Video layer* and select the *Play video* node in it.

<div align="left"><figure><img src="https://3312042618-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9sVaJpWJhPbmscipukhh%2Fuploads%2FPBrwbIdWaeIKZ7lYSnGk%2Fimage.png?alt=media&#x26;token=ebce27a9-00c7-4167-8064-d06f5f267a1f" alt=""><figcaption></figcaption></figure></div>

These graphs tell you exactly what is happening under the hood of the Play Video node:

* **Missed frames**: shows if there was a missed frame in the last few seconds.
* **Decode times**: this steps shows how much time LightAct needed for decoding the codec. HAP and NotchLC have quite low times usually, whereas H.264 and other CPU based codecs often have higher times.
* **Decompress times**: shows how much time LightAct required to unpack (decompress) the frame.
* **Buffered frame**: shows the status of the buffer. If the graph is slowly decreasing, it may indicate that the disk read speed is too slow.
* **Frame blending**: if Frame blending is enabled, this graphs shows the blending of individual frames.
