任务失败了,积分退回来了,报错说了一句你看不懂的话:
Error while downloading image, error: expected the aspect ratio to be between 0.40 and 2.50, but received image with aspect ratio: 2.80 instead
这是我们平台上一条真实任务的真实报错。下面说清楚它是什么意思、是你哪一张图的问题,以及为什么这个答案我们只能给出两个模型族的版本。
这个数是什么
这里的长宽比是宽 ÷ 高,不是你在面板里选的那个「16:9」。它量的是你挂上去的参考图,不是你要生成的视频。
Seedance 接受的参考图范围是 0.40 到 2.50。超出这个范围的图会在上游被拒——是在你提交之后,不是提交之前。
| 你的图 | 宽 ÷ 高 | Seedance |
|---|---|---|
| 9:21 超竖 | 0.429 | 接受 |
| 9:16 竖屏 | 0.563 | 接受 |
| 3:4 竖屏 | 0.750 | 接受 |
| 1:1 方图 | 1.000 | 接受 |
| 16:9 横屏 | 1.778 | 接受 |
| 21:9 超宽 | 2.333 | 接受 |
| 2.35:1 变形宽银幕 | 2.350 | 接受 |
| 3:1 横幅 | 3.000 | 拒绝 |
| 1:3 竖条 | 0.333 | 拒绝 |
大致记法:从 2:5 的竖图到 5:2 的横图之间都没问题。会出事的是全景裁切、横幅长条、以及拼接起来的胶片条。
这个数是怎么来的
不是从文档里查到的。这条限制我们没能在任何公开文档上找到。
它来自 2026-09-04 的一条失败任务。用户提交了一条 Seedance 2.5 的参考图生视频,挂了三张参考图,失败了;80 秒后重试,又失败。两次都是「提交 → 等 → 失败 → 退款」。两次的报错都报了一个长宽比数字,但没说是哪一张图。
于是我们把那条任务的三张图逐张下载下来量了一遍:
| 像素尺寸 | 宽 ÷ 高 | ||
|---|---|---|---|
| 第 1 张 | 1584 × 2816 | 0.563 | 正常 |
| 第 2 张 | 2160 × 3840 | 0.563 | 正常 |
| 第 3 张 | 2048 × 731 | 2.802 | 超上限 |
两张普通竖图,一张宽幅裁切。那张宽的把整条任务毙了——两次——而报错里没有任何东西指向它。
同一张图,换个模型完全合法
这一点值得在你动手重新裁图之前先知道。
| 模型 | 参考图长宽比 | 这个限制的来源 |
|---|---|---|
| Seedance 系 | 0.40 – 2.50 | 上面那条生产报错 —— 量的是 2.5;同系其余版本走同一适配器,但没有逐个实测 |
| 万相 3.0 | 不超过 8:1 → 0.125 – 8.0 | 阿里云百炼官方 API 文档 |
| 其余全部 | 不知道 | —— |
那张 2048 × 731、长宽比 2.802 的图,Seedance 拒,万相 3.0 完全合法。两个已知限制之间差了三倍多。
为什么我们不直接帮你拦掉
最顺手的做法是:在我们自己的界面里就把这张图拦下来,不让你白等。这个方案我们考虑过,最后否掉了,理由就是上面那张表——几十个模型,我们只量到过其中两个族的限制。按一个我们并不掌握的数去拦,等于把本来能跑的图也拒掉。
所以提交永远发得出去。对于我们没量过的模型,你要是知道一些我们不知道的,我们不会拿一个猜出来的数把你拦下。
这个选择的代价,就是你现在正在付的那个:上游拒绝时,报错报的是一个比值,不是一个文件名。在我们那张限制表还只覆盖两个模型之前,下面那个自查比等任务失败要快。
我们内部那张表现在只有两条。等哪天知道了第三条——从文档里,或者从又一次这样的失败里——就会加进去。
如果你现在正撞上这个
- 把每张参考图的像素宽高拿出来,宽除以高。
- 结果小于 0.40 或大于 2.50 的那张,就是 Seedance 上的元凶。
- 重裁的时候朝主体裁,别缩放——你要的是画幅变窄,不是内容被压扁。
- 或者把这张图拿去万相 3.0 跑,那边到 8:1 都行。
被拒的任务会退积分。你损失的是等待的时间。