> 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/settings-parameters/and-chunked.md). # \&chunked Sender-Side Option! ([`&push`](/advanced-settings/setup-parameters/push.md)) ## Options Example: `&chunked=2500` | Value | Description | | --------------- | ---------------------------------------------------------------------- | | (no value) | Enables chunked/WebCodecs publishing using the default target bitrate. | | (integer value) | Target video bitrate in kbps. Example: `2500` = about 2.5 Mbps. | ## Presets and reliability controls | Parameter | Values | Description | | ---------------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `&chunkprofile` | `mobile` \| `balanced` \| `desktop` | Applies a preset for buffer and recovery defaults. These profiles use lower starting viewer buffers than the plain chunked default. | | `&chunkedbuffer` / `&sendingbuffer` | ms | Sender-side chunk backlog target. If not set, the current base target is about `500` ms. If the flag is present without a value, it falls back to `5000` ms. | | `&chunkbuffer` | ms | Viewer-side chunk playout target. Plain chunked mode defaults to about `3000` ms if no profile or buffer override is used. | | `&chunkbufferfloor` / `&chunkbufferceil` | ms | Adaptive playout floor and ceiling for chunked viewers. | | `&chunkbufferadaptive` | `0` / `1` | Enables or disables automatic chunked playout target adjustments on the viewer. | | `&fixedchunkbuffer` | flag | Shortcut that disables adaptive chunked playout target adjustments. | | `&chunkjitterslack` | ms | Extra headroom before chunked playback rebuffers. | | `&chunkadapt` | `bitrate` \| `framerate` \| `hybrid` | Buffer-aware adaptation mode. | | `&chunkadaptfloor` / `&chunkadaptceil` | integer | Min/max clamp for the chosen adaptation mode. | | `&chunkadaptthreshold` | ms | Buffer threshold that starts adaptation. | | `&chunkadaptmaxdrop` | percent | Maximum per-step adaptation drop. | | `&chunkadaptinterval` | ms | Minimum time between adaptation changes. | | `&chunkfec` | integer | Enables parity FEC. Example: `4` means one parity packet per four data chunks. | | `&chunknack=1` | `1` | Enables selective retransmission requests for missing chunks. | ## Details `&chunked` switches video publishing from the browser's normal RTP video path to a custom chunked transport built on WebRTC data channels. The sender uses encoded output, slices it into chunks, and sends those chunks directly to viewers. This mode is useful when you want tighter control over bitrate, buffering, recording, or recovery behavior than the normal browser-managed RTP path allows. It is especially relevant for recording-first workflows, high-quality one-to-many publishing, and experimentation with FEC/NACK/buffer adaptation. ### Important behavior notes * `&chunked` is a sender flag. If present without a valid number, VDO.Ninja still enables chunked mode and uses the default chunked bitrate target. * Sender-side backlog is controlled with [`&chunkedbuffer`](https://github.com/steveseguin/vdo.ninja/blob/gitbook/advanced-settings/newly-added-parameters/and-chunkedbuffer.md), not with viewer [`&buffer`](/advanced-settings/video-parameters/buffer.md). * Viewer playout behavior is controlled with `&chunkbuffer`, `&chunkbufferfloor`, `&chunkbufferceil`, `&chunkbufferadaptive`, and `&chunkjitterslack`. The older viewer `&buffer` value can also override the chunked viewer target, but `&chunkbuffer` is clearer for chunked-specific tuning. * Chunked mode can be used with [`&retransmit`](/advanced-settings/settings-parameters/and-retransmit.md) for chunked relay workflows. * `&nochunked` disables the chunked path, and `&nochunkaudio` disables the chunked audio portion when applicable. ### Default buffer delay and changing it Chunked mode uses its own viewer-side buffer. If you enable `&chunked` without a chunk profile or buffer override, the viewer target starts at about: ``` 3000 ms ``` You can change that viewer delay with: ``` &chunkbuffer=1000 ``` Lower values reduce delay, but give the connection less time to recover from jitter or packet loss. Higher values add delay, but can make recording and playback steadier. Examples: ``` &chunkbuffer=750 &chunkbuffer=1500 &chunkbuffer=3000 ``` The `&chunkprofile` presets also change the starting buffer target: * `&chunkprofile=mobile` starts around `900 ms` * `&chunkprofile=balanced` starts around `750 ms` * `&chunkprofile=desktop` starts around `620 ms` Those profile values are lower latency starting points, not guarantees. The viewer can still adapt within the configured floor and ceiling unless adaptive buffering is disabled. For more control, use: ``` &chunkbuffer=1000&chunkbufferfloor=700&chunkbufferceil=2000 ``` To keep the target from automatically adjusting, use: ``` &fixedchunkbuffer ``` or: ``` &chunkbufferadaptive=0 ``` ### External music-sync workflows For NINJAM-style or loop-based music setups, the common pattern is: * keep the real audio path outside VDO.Ninja, often in OBS or another music-sync tool * delay the chunked **video** enough to match that external audio * drive the delay live via the iframe API using `setBufferDelay` Typical viewer flags for that workflow are: ``` &noaudio&chunkbufferadaptive=0&chunkbufferceil=180000 ``` Notes: * `&chunkbufferadaptive=0` or `&fixedchunkbuffer` keeps the target fixed instead of letting the viewer auto-raise it. * `&chunkbufferceil=180000` allows up to 3 minutes of delayed **video** playback. * This is mainly a long-delay video-sync workflow. For very large delays, chunked audio is usually better handled externally rather than relying on VDO.Ninja's in-page audio playback path. ### Why use it * Better control over bitrate and queueing than the normal RTP path * Better fit for direct-to-disk recording of encoded chunks * Supports chunk-level recovery options such as parity FEC and NACK-based retransmits * Can be relayed without transcoding in supported workflows ### Recording with chunked mode Chunked mode can be useful when the recording path can tolerate more delay than the live conversation path. For example, you might use: * a chunked, buffered view for OBS recording * a separate normal WebRTC view for lower-latency monitoring or guest conversation Viewers decide whether to use the chunked path. If a viewer should ignore the chunked version and connect with the normal lower-latency WebRTC path, add: ``` &nochunked ``` This can let one production source prioritize steadier recording while another source keeps delay lower. Chunked recordings can also be written directly to disk from the encoded chunks without re-encoding the video. This can reduce CPU load and avoid an extra encode generation, but the workflow should still be tested before a real session. ### Tradeoffs * This path is more experimental than standard WebRTC RTP video * It depends heavily on modern Chromium-class browser support * It introduces explicit buffering and can pause to recover instead of degrading as gracefully as RTP in some cases * It is not the default behavior and should be treated as an opt-in transport mode ### Compatibility notes * Chunked mode is primarily intended for recent Chromium-based browsers and related runtimes. * It is still a moving target, especially around browser codec support, alpha-channel support, and advanced recovery behavior. * If using `&alpha` with `&chunked`, encoder availability still depends on the browser/runtime. ## Related {% content-ref url="" %} {% endcontent-ref %} {% content-ref url="/pages/eqd66SGb0Enj0YDLwElo" %} [\&nochunked](/advanced-settings/settings-parameters/and-nochunked.md) {% endcontent-ref %} {% content-ref url="/pages/6rDMxFD7pJ6hlVMQHnjp" %} [\&retransmit](/advanced-settings/settings-parameters/and-retransmit.md) {% endcontent-ref %} {% content-ref url="/pages/CGSJcLuypaByekwow0QH" %} [Recording video with consistent results](/guides/recording-video-with-consistent-results.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: ``` GET https://docs.vdo.ninja/advanced-settings/settings-parameters/and-chunked.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.