GoForum🌐 V2EX

被 Web 端 FFmpeg 折磨了:进度总卡在 99%,求大佬指点

jsxyzb · 2026-05-09 13:05 · 0 次点赞 · 3 条回复

我把自己日常要用的一个视频处理需求做成了在线工具:videosnap.cc

本来目标很朴素:

  • 不用装软件
  • 尽量浏览器本地处理
  • 少上传原视频,降低隐私顾虑

结果最近被一个问题狠狠干懵了:处理进度卡在 99% 很久,没挂但就是不结束。


## 复现现象(真实可复现)

在部分机器 + 中大视频文件下:

  • 前面进度推进正常
  • 到 99% 后长时间不动
  • CPU 看着还在跑
  • 页面不报错
  • 用户体感就是:“卡死了”

## 我目前的判断

大概率是尾段组合问题,不是单点 bug:

  1. ffmpeg.wasm 处理结束后,JS 侧 Uint8Array/Blob 搬运开销太大
  2. Worker <-> Main thread 消息传递产生了额外 copy
  3. MEMFS / WORKERFS 在大文件尾段读写时可能有阻塞;OPFS 还没来得及完整验证,准备继续试

## 已尝试(但还没彻底解决)

  • 调 ffmpeg 参数,减少中间产物
  • 主流程尽量放到 Worker
  • 尝试 WORKERFS
  • 尝试 OPFS
  • 控制并发,压低内存峰值
  • 修正进度条策略(避免“假 100%”)

## 想请教各位的关键问题

  1. 你们做 Web 端 ffmpeg 时,有没有遇到这种“99% 假完成”?
  2. 大文件场景下,最终导出阶段你们是怎么设计的?
  3. OPFS 在真实生产里是否明显优于 MEMFS/WORKERFS
  4. 有无推荐的排查维度:内存曲线、拷贝次数、阶段耗时埋点等?

项目地址:https://videosnap.cc 先谢过各位 🙏

3 条回复
qxmqh · 2026-05-09 13:10
#1

你看看我的 https://fastcut.video

Perry · 2026-05-09 13:10
#2

现在推广自己做的 AI Slop 都这么发帖了? AI 写的文案自己读过没,不尬么?

andyskaura · 2026-05-09 13:25
#3

虽然你这是推广,不过我也说下前两天遇到的现象和你的很像。 在做大文件断点续传的时候,mac 上都很正常。 但在 windows 上 createWritable 如果开启次数频繁,哪怕写不同位置,也会导致报错:“An operation that depends on state cached in an interface object was made but the state had changed since it was read from disk.”。

windows chrome 老版本的 File System Access API 的 writable 行为更不稳定。

添加回复
你还需要 登录 后发表回复

登录后可发帖和回复

登录 注册
主题信息
作者: jsxyzb
发布: 2026-05-09
点赞: 0
回复: 0