> 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/and-buffer2.md).

# \&buffer2

Same as \&buffer, but instead includes the round-trip-time

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: `&buffer2=500`

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

## Details

`&buffer2=500` requests buffering like [`&buffer`](/advanced-settings/video-parameters/buffer.md), while also accounting for an estimate of network transit time. The normal WebRTC calculation subtracts **half the available round-trip time (RTT)** as an estimate of one-way delay. For example, a 200 ms RTT contributes a 100 ms subtraction, not 200 ms. Measured jitter-buffer delay also affects the adjustment, so the requested value is not an exact end-to-end latency guarantee.

The viewer obtains this RTT from the browser's selected ICE candidate-pair statistics. It does not require a custom statistics report from the publisher. If the browser does not expose a usable RTT, the RTT correction cannot be applied.

`&buffer2` does not enable explicit audio sync compensation. If changing the buffer separates audio from video, add [`&sync=0`](/advanced-settings/audio-parameters/sync.md) to the viewer URL before connecting. This also works with iframe `setBufferDelay`; `&buffer2` is optional. If an external sync system already measures stream offsets, it can use `&sync=0` with the API without adding RTT compensation.

It won't work that well with [Meshcast](/advanced-settings/meshcast-parameters/and-meshcast.md).

Accuracy and settling time depend on the browser and connection. This is not a frame-accurate timing control.

## Related

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

{% content-ref url="/pages/-MZdvss-ktTf4GVpebJs" %}
[\&sync](/advanced-settings/audio-parameters/sync.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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.