Skip to main content

Resolution cap: roughly 132.7 megapixels per capture

The largest capture is Full HD at 8x supersampling (15360 x 8640). Anything beyond this is rejected up front with a clear log message. At 16 bytes per pixel a capture near the cap peaks around 2 GB, so larger captures would run the editor out of memory inside the readback. To work around it: lower the Size Multiplier, or capture at base resolution and upscale externally. 8K (33 MP) and 4K at 2x SSAA (33 MP) fit comfortably; Full HD at 8x (132.7 MP) is the largest that fits, so anything beyond it, such as 4K at 8x, is rejected.

AOV passes on the Built-in render pipeline

The lighting and data-buffer shaders are URP-targeted. On Built-in they fall back to a Diffuse render, so a request for Normals or Motion Vectors will produce a lit image instead. Switch to URP for full fidelity. HDRP is detected and reported but not actively supported.

Transparent capture disables post-processing by default

The standard transparent path renders the camera with an alpha-cleared background, which Unity uses as a signal to skip post-processing. The Post-Process Only and Hybrid alpha sources work around this with a dual black-and-white render, so pick one of those if you need bloom or grading in a transparent screenshot.

GIF recording memory cap

The in-memory frame buffer is capped at 512 MB. If your duration x resolution x frame rate would exceed that, the recorder caps the duration, logs a warning, and you get a partial GIF instead of a crash. To capture longer or higher-resolution GIFs, drop the resolution to Half or Quarter.

GIF finalisation takes time

Encoding runs on a background thread after Stop Recording. The window stays responsive but the .gif file is written when encoding finishes, so wait for OnEncodingComplete or watch EncodingProgress when scripting.

Simple RGB24 vs Multi-layer EXR Cryptomatte

Simple RGB24 produces hue-rotated PNGs that are not loadable as real Cryptomattes in Nuke / Fusion / AE; they are for thumbnail preview only. Use Multi-layer EXR for actual compositing.

Recording requires Play Mode

GifRecorder and SequenceRecorder both refuse to start outside Play Mode and log an error. In the window you rarely notice: the Record tab’s Record button enters Play Mode and starts the recording automatically, and the Gif tab offers Auto-Record on Play. Turntable video recording is the exception: it renders deterministically in Edit Mode.

Video and GIF capture never stalls the frame

Frames are read back with AsyncGPUReadback (no ReadPixels pipeline stall), buffered, and encoded under a per-frame time budget, so encoder spikes spread across several frames instead of freezing one. If the GPU or the encoder falls behind, further capture slots are skipped and held, so a heavy scene records with held frames instead of collapsing the frame rate. Every video take ends with a performance summary line in the Console showing average and peak capture and encode cost, pipeline depth, and the drop count, so a slow take tells you which stage was the bottleneck.

Game speed changes while recording

Live video recording follows the Pacing switch above the Record button, and under both pacings the game’s frame rate is capped to the recording frame rate while a recording runs (restored on stop): frames above that rate would never reach the file and would only starve the capture and encode work of headroom. Gameplay (the default) records in real time. Smooth locks the engine clock to the frame rate for a perfectly even file, so on a machine that cannot hold the rate, game speed slows with rendering performance instead of losing frames. Turntable renders are deterministic and ignore the switch.

VP8 is slow for live recording

WebM (VP8) encoding costs far more per frame than H.264. With Prefer H.264 For Live on (the default), live recordings without transparency automatically write MP4 (H.264) even when WebM is selected; turntable renders always honour the chosen format. Turn the toggle off in the Record tab’s Output section to force VP8 live. For opaque WebM, a faster route is the ffmpeg encoder’s VP9 codec (Settings > Recording > Use ffmpeg).

How can I tell whether ffmpeg encoded my video?

The output file deliberately looks the same either way, so read the Console: the take starts with Encoding through ffmpeg (...) on a background thread when ffmpeg is doing the work, or a fallback warning with the reason when it is not, and the completion log names the encoder that produced the file (... via ffmpeg H.264 -> ...). While recording, an ffmpeg process is visible in your system’s task manager. The file itself also carries the evidence: ffprobe or MediaInfo shows an encoder: Lavf... tag on ffmpeg-written files, which Unity’s built-in encoder never writes.

Recording logs “Using the camera re-render path”

Live recording is cheapest when it can copy the already-composited screen. That fast path needs an opaque take with post-processing on, no supersampling, the main camera as the source, and a Game View aspect close to the output’s (a small mismatch is handled by cropping the centred region). When any condition fails, the recorder renders the scene a second time per captured frame and logs exactly which condition was responsible. Matching the Game View aspect to the output resolution, or recording the main camera, brings the cheap path back.

Video quality and bitrate

The Quality preset in the Record tab sets the encoder’s target bitrate: Low 5, Medium 8 (the default), High 10, and Ultra 25 Mbps. Custom exposes an explicit 1 to 200 Mbps slider.

Panoramas skip post-processing

Cubemap rendering bypasses post-processing and screen-space effects; this applies to every equirect capture tool in Unity. RenderToCubemap also requires render pipeline support; if the capture fails, the error notes the active pipeline as the likely cause.

Sequence folder collisions

If your sequence output folder already contains frames, the recorder warns but proceeds. Pick a new folder per take if you do not want previous frames overwritten.

Clipboard support by platform

On Windows the clipboard holds both a universal bitmap and a PNG (transparency survives in apps that support it). macOS and Linux support is editor-only and best-effort; Linux needs xclip on the PATH.