Limits
What this can actually handle
Video Mender does not claim unlimited anything. These are the ceilings it enforces, the reasons behind them, and what happens when you exceed one.
The ceilings
| Limit | Desktop | iPhone / iPad | Why |
|---|---|---|---|
| File size — rewrap | 1.3 GiB | 384 MiB | Rewrapping never decodes a frame, so it tolerates far larger files. |
| File size — re-encode | 1.0 GiB | 256 MiB | Decoding holds uncompressed frames in memory, which is the real constraint. |
| Clip length — re-encode | 4:00:00 | 30:00 | Beyond this, progress reporting and memory behaviour stop being dependable. |
| Resolution — re-encode | 4096 × 2160 | 1920 × 1080 | A 4K frame is about 12 MB decoded, before the encoder allocates anything. |
Why these numbers
The binding constraint is memory, and the hard edge is the engine rather than your machine. FFmpeg here is compiled to WebAssembly as a 32-bit program, so everything it touches — the engine itself, your source file, the decoded frames and the finished output — has to fit inside a single 4 GiB address space. A workstation with 64 GB of RAM does not raise that ceiling by one byte, which is why these figures look modest next to a desktop application.
Inside that space, decoding is what consumes it. An uncompressed 4K frame is roughly 12 MB, a decoder holds a window of reference frames, and the encoder holds its own lookahead. A single 4K re-encode can therefore need well over a gigabyte of working memory for a file that is only a few hundred megabytes on disk.
That is why rewrapping and re-encoding have such different limits. A rewrap copies compressed streams and never decodes a frame, so it costs little more than the file itself, so its ceiling is roughly twice the file size. A re-encode is a different order of expense entirely.
iOS gets tighter limits because Safari on iPhone and iPad kills a tab under memory pressure with no warning and no recovery. Refusing a job is a much better outcome than losing a queue halfway through, so the ceilings there are deliberately conservative.
What happens at the limit
- Each file is checked before it is scheduled. A job outside the ceilings is marked unsupported with the specific reason, and the rest of the queue runs normally.
- On top of the fixed ceilings, every job gets a memory estimate from its own resolution and size, compared against what your device reports. That is what decides how many files run at once.
- A file too large to re-encode may still be well within the rewrap limit. If the codecs already fit the target container, turn fast rewrap on and it will go through.
Getting a large file through anyway
- Cap the resolution. Dropping 4K to 1080p removes about three quarters of the pixels and is the single most effective change.
- Use a desktop browser rather than a phone. The ceilings are several times higher.
- Close other tabs before starting. The memory budget is a share of what the whole browser has.
- Download each result before starting the next, so finished outputs are not held in memory.
- Check whether the job needs re-encoding at all — the queue tells you per file, and a rewrap has far more headroom.