任務失敗了,積分退回來了,報錯說了一句你看不懂的話:
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 都行。
被拒的任務會退積分。你損失的是等待的時間。
