fix: videoRatio aspect ratio parsed as resolution causing scale=9:1920 #1364
Reference in New Issue
Block a user
Delete Branch "fix/video-ratio-resolution-parsing"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Root Cause
videoRatio stores aspect ratio format (e.g. "9:16") but useGenerateVideo.ts parsed it as resolution with .split("x"). parseInt("9:16", 10) returns 9, causing FFmpeg scale=9:1920 to fail.
Fixes
Root cause: videoRatio stores aspect ratio format (e.g. "9:16") but useGenerateVideo.ts parsed it as resolution with .split("x"), causing parseInt("9:16") to return 9 instead of 1080. Fixes: - Frontend: parse aspect ratio (colon format) and compute pixel dims - Backend worker: guard output_width < 100, fallback to default - Backend render_adapter: guard width/height < 100 in _parse_resolution - API schema: add ge=100 validation on ConfirmGenerationRequest🚀 预览环境已部署
【阻塞级判定】
📊 审查概览
🔴 阻塞级问题(必须修复)
baseShort - (baseShort % 2)。当宽高比差异极大(如 2000:1)时,baseShort计算结果可能为 1(例如Math.round(1920 * 1 / 2000) = 1)。此时1 - (1 % 2)结果为0。导致发送给后端的output_width或output_height为 0,触发后端 Pydantic 验证错误(ge=100),导致生成任务失败。const evenShort = Math.max(2, baseShort - (baseShort % 2))。💡 改进建议(不阻塞合并)
ge=100的限制,但在处理 "1080x1920" 格式时,前端仅使用parseInt(..., 10) || 1080。如果用户输入或配置传入 "50x1920",前端会正常解析并发送 50,随后被后端拦截(422 Error)。建议在前端解析时也增加最小值校验(如Math.max(100, parseInt(...))),提升用户体验,避免无效请求。✅ 良好实践
generation.py和render_adapter.py中增加了< 100的校验和日志记录,有效防止了前端误传宽高比字符串(如 "9:16" 被解析为 9)导致的渲染崩溃。generation_task.py中为output_width/height添加了ge=100约束,从数据模型层保证了数据的合法性。✅ 格式检查通过 | ❌ 逻辑审查需修改 | ✅ 性能良好
🤖 由 AI 代码审查机器人自动生成 | 2026-08-13 16:20:43 | 模型:
CI全绿,自动审批通过。
CI全绿,自动审批通过。
🗑️ 预览环境已清理
PR #1364 已关闭或合并,对应的预览环境已被清理。