> 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/recording-parameters/and-recordcodec.md).
# \&recordcodec
Lets you set the video recording codec
Sender-Side Option / Director Option! ([`&push`](/advanced-settings/setup-parameters/push.md), [`&director`](/advanced-settings/director-parameters/director.md))
## Aliases
* `&rc`
## Options
Example: `&recordcodec=h264`
Value
Description
h264
request the h264 codec
vp8
request the VP8 codec
vp9
request the VP9 codec
av1
request the AV1 codec
mp4
request the MP4 container with browser-selected codecs
## Details
### MP4 recording
Use `&record=12000&recordcodec=mp4` to request an MP4 recording. `&rc=mp4` is the shorter alias. Add `&splitrecording=1` for independent one-minute disk-only segments.
This selects the MP4 container and lets the browser choose its supported codecs. Safari 26 on a real iPhone produced H.264 video and AAC audio in testing. The option changes recording output, not the live WebRTC codec or bitrate. Defaults remain unchanged.
Short real-iPhone tests verified intact saved MP4 files and native player recognition. A longer Safari 26.6 attempt produced eight independently decodable one-minute encoder segments at 1080p/\~30 FPS, but BrowserStack control timed out before final download and native playback checks. Full 15-minute saved-file/playback qualification remains pending; these results do not establish long-session reliability or lip sync.
A focused follow-up retrieved both actual MP4 downloads, verified their bytes, and played both to the end in Safari with fullscreen active. The managed device's Files app was unavailable, so this does not certify opening the files through Files/Quick Look. MP4 remains opt-in.
| Situation | Outcome |
| ------------------------------------------------------ | ------------------------------------------------------------------------------- |
| Browser supports MP4 recording | Requests `video/mp4` and saves `.mp4` files. |
| MP4 recording is unsupported, including tested Firefox | Uses the existing recording fallback, normally WebM. Check the saved extension. |
| MP4 constructor fails and WebM is supported | Local recording retries WebM and saves `.webm`. |
| PCM or audio-only recording | Keeps the existing PCM/audio path; this MP4 video option does not override it. |
| `&recordcodec=h264` | Requests H.264 in the existing WebM path; it does not select MP4. |
Use MP4 when your player/editor needs it, especially for Apple native playback. It does not fix Android H.264 timing problems or guarantee a requested bitrate/frame rate. Browser support and encoder behavior still need qualification for the device in use.
Adding `&recordcodec` to a source or director link controls video recording output (saving to disk mode; aka [`&record`](/advanced-settings/recording-parameters/and-record.md)). Codec values such as `h264` and `vp8` use the existing WebM path, with browser-dependent fallback. The special value `mp4` selects the MP4 container as described above. Unsupported choices fall back; verify the resulting file format.
As a guest or source side don't forget to add [`&record`](/advanced-settings/recording-parameters/and-record.md) to the URL to get the record button.
## Older Android phones
Try `&quality=1&recordcodec=vp8` first if high-resolution recording struggles. `&quality=1` requests 720p capture, so it also changes the source used for streaming.
In September 2026 testing on a Pixel 4a running Chrome 151, native-camera recording at a requested 12 Mbps achieved approximately 20 FPS at 720p with VP8, versus 9 FPS at 1080p. H.264 improved native 1080p cadence to approximately 20 FPS, but a separate controlled 720p H.264 test repeatedly developed multi-second A/V drift. The H.264/Opus WebM file also failed to play in Google Photos on that phone despite decoding in FFmpeg.
These are device-specific results, not browser-wide guarantees. Before choosing H.264, test a saved file for synchronization and compatibility with your intended player or editor. Existing defaults remain unchanged.
A follow-up on Chrome 152 reproduced the H.264 drift with bare MediaRecorder, without VDO.Ninja or streaming. VP8 stayed stable in the same controlled-source test. Changing the app's recording writer would not address that reproduced browser-path problem.
On Safari 26, WebM recording support also does not guarantee playback in Apple's native Quick Look: an iPhone test saved an intact VP8/Opus WebM file, but Quick Look offered file information without playback. An older Safari 16 iPad selected MP4 automatically and its saved file played in Quick Look.
## Related
{% content-ref url="/pages/-MZXYl\_nYDzfbdqy-AuC" %}
[\&record](/advanced-settings/recording-parameters/and-record.md)
{% endcontent-ref %}
{% content-ref url="/pages/-MZdudjg0hJYNiC3VGwt" %}
[\&codec](/advanced-settings/video-parameters/codec.md)
{% endcontent-ref %}
{% content-ref url="/pages/-MZXUH\_TcAPR6tvYbLlI" %}
[\&pcm](/advanced-settings/recording-parameters/and-pcm.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/recording-parameters/and-recordcodec.md?ask=&goal=
```
`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.