> For the complete documentation index, see [llms.txt](https://docs.vdo.ninja/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vdo.ninja/advanced-settings/video-parameters/buffer.md).

# \&buffer

Sets the video buffer

Viewer-Side Option! ([`&view`](/advanced-settings/mixer-scene-parameters/view.md), [`&scene`](/advanced-settings/mixer-scene-parameters/scene.md), [`&room`](/advanced-settings/setup-parameters/room.md))

## Options

Example: `&buffer=500`

| Value           | Description |
| --------------- | ----------- |
| (numeric value) | delay in ms |

## Details

This feature will increase the size of the audio and video *playout delay* by means of tweaking the webRTC *jitter buffer* pipeline (or a related buffer).

Current VDO.Ninja code clamps normal WebRTC receiver buffer hints to **0-4000 ms**. These are requests to the browser, not a guarantee of the resulting delay or an upper bound on total end-to-end latency. The browser may honor less, add its own buffering, or take time to settle after a change.

While in theory this option can also help to improve video and audio quality, as a larger playback buffer should help reduce the effects of network jitter and packet loss, it's not a miracle solution in this regard. Adding 200-ms of buffer delay using this feature is worth trying however, as some users have reported it has helped improve their connections.

The problem is that the browser doesn't fully make use of the available buffer if set high, and so it's largely used as mainly a hint. Network conditions, memory limits and other factors may impact the results as well.\
\
Older browser versions behaved differently. For current native WebRTC playback, do not rely on a request above 4000 ms producing more video delay. An enabled audio compensation node can still add audio delay, so oversized requests can separate audio from video.

### Keeping audio synchronized when changing the buffer

If audio and video are synchronized initially but separate when you change the buffer, add [`&sync=0`](/advanced-settings/audio-parameters/sync.md) to the **viewer URL before connecting**. This enables a Web Audio delay node that tries to compensate audio as the requested buffer changes, including changes through iframe [`setBufferDelay`](/guides/iframe-api-documentation/iframe-api-basics.md).

This is a viewer-side setting for normal WebRTC input. `&sync=0` does not require `&buffer2` or chunked mode. Browser buffer changes are approximate and may take time to settle; this is not a frame-accurate playout guarantee.

### Example values

`&buffer=0` requests minimal browser buffering. Add [`&sync=0`](/advanced-settings/audio-parameters/sync.md) separately to enable explicit audio compensation.

`&buffer=100` requests a 100 ms buffer target; it is not necessarily another 100 ms on top of the existing browser delay.

`&buffer=200` can help reduce video problems, such as frame jitter, with 200-ms of added delay.

If the issue is short random packet loss rather than jitter, [`&codec=vp8&vred`](/advanced-settings/video-parameters/vred.md) is another advanced normal-WebRTC experiment to compare. It does not replace buffering; it only asks negotiation to prefer video RED when the browser supports it.

{% hint style="warning" %}

* This feature will only work if playing the video in Chrome or Chromium-based browsers of around version 80 and newer.
* OBS v27.1.3 or older (on PC) uses v75 though, so you will need to update to OBS 27.2 or newer to use it there.
* The Electron Capture app also supports the `&buffer` command, along with vMix using a compatible Chromium version.
* Using the `&buffer` command may stop [Echo Cancellation](/advanced-settings/audio-parameters/aec.md) from working due to the audio delay this feature produces.
* Beyond 3-seconds of buffering may cause audio/video sync issues.
  {% endhint %}

{% hint style="info" %}
Use [`&sync=0`](/advanced-settings/audio-parameters/sync.md) to enable audio compensation while adjusting the buffer. A nonzero `&sync` value adds an audio offset relative to that compensation. The browser's normal buffering alone may not keep both tracks aligned during changes.
{% endhint %}

## Chunked mode

When using \&buffer with a stream that is being sent using chunked-mode ([\&chunked](/advanced-settings/settings-parameters/and-chunked.md)), the method of buffering will be different as it doesn't rely on the built-in system playout webRTC buffer delay function.

Chunked buffering has separate limits: shared audio/video targets are capped at **30000 ms**. The video-only ceiling defaults to **180000 ms** and can be configured with `&chunkbufferceil`; memory, decoding, and actual playback behavior still limit practical use.

As well, the buffering works to buffer the stream, in a way similar to HLS or RTMP buffering.\
\
The default chunked viewer buffer depends on how chunked mode is being used. Plain `&chunked` starts around 3000-ms if no profile or buffer override is used, while `&chunkprofile` presets use lower starting targets. For clearer control with chunked mode, use `&chunkbuffer`, `&chunkbufferfloor`, and `&chunkbufferceil`.

Current shared chunked audio/video buffering is limited to about 30 seconds. Minute-long chunked buffering is therefore best treated as an experimental video-only path; use HLS or an encoded OBS/server workflow when synchronized audio and video must be delayed by minutes.

Please refer to \&chunked mode for more details, but it could be an option if your goal is to improve stream stability under high packet loss. Recent Chromium-based runtimes are the primary target. Firefox publishing is disabled, while Safari/WebKit publishing is enabled only when its complete WebCodecs and worker track-processing stack passes VDO.Ninja's capability checks.

For the separate audio-node capacity and examples of reducing compensation with `&sync=-100`, see [`&sync`](/advanced-settings/audio-parameters/sync.md#negative-sync-reduce-added-audio-delay). Negative buffer values do not provide negative latency; use zero for minimum practical buffering.

## Update in [v23](/releases/v23.md)

The option to right click a remote video and add/adjust the [`&buffer`](/advanced-settings/video-parameters/buffer.md) delay for that specific video dynamically.\
![](https://2943598173-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZHXv1G8N0MDxwotaT9%2Fuploads%2F4AhfDQ7nJYZsU3bkiPuv%2Fimage.png?alt=media\&token=88547508-92eb-4392-a69b-e6fd335d9e4d)

## Related

{% content-ref url="/pages/h2JmCAiOBzHayGu72EVo" %}
[\&buffer2](/advanced-settings/video-parameters/and-buffer2.md)
{% endcontent-ref %}

{% content-ref url="/pages/-MZdvss-ktTf4GVpebJs" %}
[\&sync](/advanced-settings/audio-parameters/sync.md)
{% endcontent-ref %}

{% content-ref url="/pages/y3TIjGr6X9edZjK2NOU9" %}
[\&vred](/advanced-settings/video-parameters/vred.md)
{% endcontent-ref %}

{% content-ref url="/pages/IfGJAmmDnOW1EFXgyKiW" %}
[Delay an incoming feed](/guides/delay-an-incoming-feed.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.vdo.ninja/advanced-settings/video-parameters/buffer.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
