fix(cover): extract cover from source asset when no backend preview exists #1459
Reference in New Issue
Block a user
Delete Branch "fix/cover-extract-from-source-asset"
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?
问题
前端预览已改为纯 Canvas/WebCodecs 浏览器内渲染,不产生后端 GenerationTask 或渲染视频。封面 API 的步骤 A-D 全部依赖后端产物(cover_url / cover_candidates),全部落空后返回 400。
此外,原代码在进入 A-D 之前还有一道早期
rendered_storage_key400 闸门,即使有素材也无法进入兜底抽帧逻辑。改动
asset_ids中选取第一个视频素材,直接对源素材 URL 调 MediaKit 抽帧,转存到 OSS covers/ 路径。_persist_cover_frame工具函数:下载 MediaKit 临时帧图并上传 OSS。ec4071eb中已 404 的陈旧rendered_storage_key。测试
🚀 预览环境已部署
CI全绿,自动审批通过。
CI全绿,自动审批通过。
代码审查结果 - PR #1459
⚠️ 问题(3个需要修改)
for aid in body.asset_ids循环未对迭代次数做限制。如果用户传入包含大量ID的数组,会导致频繁的数据库查询和外部API调用,可能造成服务响应缓慢甚至拒绝服务。storage.upload_file成功但storage.get_url返回None时,代码回退返回了原始的frame_url。这会导致OSS中已存储的文件无法被引用,同时返回的临时URL可能很快失效,造成封面丢失。not resp.content)时,直接返回原始frame_url是不合理的,这说明上游服务返回了异常数据,应视为失败处理,否则可能将无效链接存入数据库。💡 建议(2个可选)
import tempfile,import uuid等库的导入语句移至文件顶部。虽然在函数内导入可以避免循环依赖或减少启动开销,但在频繁调用的热路径函数中,重复导入会带来微小的性能损耗。mk_client.is_available的检查。虽然循环外已检查,但如果循环耗时较长,期间服务状态可能发生变化,双重检查更稳健。❌ 逻辑审查需修改 | ⚠️ 建议关注性能
🤖 由 AI 代码审查机器人自动生成 | 2026-08-22 15:10:28 | 模型:
🗑️ 预览环境已清理
PR #1459 已关闭或合并,对应的预览环境已被清理。