Pixel pairs against named ratios for the same job
One page gives shape as pixel pairs from 1280:720 to 672:1584. The other gives six named ratios and requires the field on the text path. Both answer what shapes exist; only one answers how many pixels arrive. As of 2026-09-22.
| What the pages state | Runway | MiniMax |
|---|---|---|
| Shapes available | Seven pairs | Six named ratios |
| Pixel count | Printed in the value | Not printed anywhere |
| Comparable across the column | Only by arithmetic | Directly, against other names |
Inclusion rule. Shape statements from each page, kept in the units each uses. Pairs are not converted to ratios and ratios are not converted to pixels. Order. What each cell offers first, then what it settles.
1A pixel floor is checkable on one row only
The platform in this register that publishes minimum dimensions accepts square from 640x640 upward. A pair reading 960:960 settles that in one step. A ratio reading one by one does not, because the page never says how large a one by one frame comes back.
That is the practical argument for pairs. It is also the argument against them: the pair row cannot be lined up beside thirteen rows publishing names without arithmetic these sheets refuse to publish as a fact.
2The named row makes the field compulsory
On the text path the ratio is required and adaptive is explicitly not offered, so nothing comes back in a shape nobody chose. The pair row documents its values for the image-conditioned path, where an input frame has already decided.
Both arrangements remove the same risk by different means. Neither leaves the shape to a default, which puts them among the safer rows in this column for unattended batch work.
3The pairs bound the output lower than the names suggest
The largest long side on the pair page is 1584 pixels, under 1080p on its long axis. The named row publishes 768P and 2K on one model and 480P and 768P on the other, so its top rung is well above anything the pairs reach.
A shape column read alone would miss that entirely. It is the reason these sheets carry the pairs in the resolution column as well, marked as pairs rather than tiers, so the ceiling is visible wherever a reader starts.
4The rest of the column behind these two
| Generator | Aspect ratio |
|---|---|
| Amazon Nova Reel | Not stated |
| CogVideoX | Not stated |
| Google Veo | 16:9 and 9:16 |
| Grok Imagine | Seven, 16:9 the default |
| Hedra | Seven, including 9:21 and 21:9 |
| HeyGen | 16:9 or 9:16 |
| Kling AI | Not stated |
| LTX-Video | Not stated |
| MiniMax | Six, required for text-to-video |
| Pika | Not stated |
| PixVerse | Eight on version 6 |
| Runway | Seven pixel pairs |
| SceneMixer | 9:16 and 16:9 |
| Vidu | Not stated |
| Wan 3.0 | Six, adaptive by default |
Inclusion rule. Every generator this register carries, on the one column this pair disagrees about. Rows that state nothing keep their place and are marked hollow. Order. Alphabetical by generator name.
Why these two. These are the two ways this column gets published, and each is opaque exactly where the other is clear. A placement with a pixel minimum can be checked against one of them and not the other.
- Gen-4.5 image-to-videoLandscape 1280:720, 1584:672 and 1104:832, portrait 720:1280, 832:1104 and 672:1584, square 960:960shape given as a pixel pair rather than a ratio
- Aspect ratios; for image-to-video the ratio follows the input image21:9, 16:9, 4:3, 1:1, 3:4 and 9:16, required and never adaptive for text-to-video
5Sources
Read from the Runway API input reference and the MiniMax video task reference, both checked 2026-09-22. The column is described on aspect ratio, and each entry has its own cell page at Runway and MiniMax, and the rule that keeps surfaces and generators apart is on method. Nearby pairs: Wan 3.0 and MiniMax, Grok Imagine and Pika.