Sets the video buffer

Viewer-Side Option! (&view, &scene, &room)


Example: &buffer=500


(numeric value)

delay in ms


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).

This can effectively be used as a way to delay the incoming video and audio by upwards of around 10-seconds. It's compatible with modern Chromium-based browsers.

While in theory this option can also help to improve video and audio quality, as a larger playback buffer can 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.

While one might think adding 10-seconds of buffer would then only improve the connection further, at this point it doesn't really. Work is being done to change this however, such as the work related to the &chunked transfer mode, which will work quite well with extended buffer times.

Example values

&buffer=0 will force the audio to be in sync with the video, with the video playing back with minimal delay.

&buffer=100 will add a 100-ms time delay to the video, on top of any existing delay.

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

  • 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 from working due to the audio delay this feature produces.

  • Beyond 3-seconds of buffering may cause audio/video sync issues.

You can refer to the &sync command if you wish to delay the audio, relative to the video. &buffer will try to keep the audio and video in sync, which might always be desired.

Chunked mode

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

The practical benefit of using &chunked mode with &buffer is that you can have buffers that are minutes long, up to whatever your system's resources can handle.

As well, the buffering works to buffer the stream, in a way similar to HLS or RTMP buffering. The default buffer is around 1-second actually when using &chunked mode, as it requires a buffer to avoid playback issues. If the buffer underruns, the stream may fail.

Please refer to &chunked mode for more details, but it could be an option for you if your goal is to improve the quality of streams when facing high-packet loss. It's only compatible with Chromium-based browsers; not Firefox or Safari as of yet.

Update in v23


Last updated