@v423 移动端别指望了。肯定是上传服务端稳定。转码出了问题，你都没办法跟踪，因为片源在用户手机上。以前有个项目，要把手机上拍摄的几段片子和其他预制素材合成一个短视频。领导天真的说，要把转码放在用户手机上做。结果各种问题，用户下载预制素材都会下载失败，结果转码失败。完全没法跟踪。而且用户的低端手机转码速度完全不可控，导致用户体验完全不一致。

试了下我的电脑，720p 视频转 2m720p 输出，只有 1x 的速度。所以一分钟就要等 1 分钟。手机上也好不到哪里。 web+wasm 页面的问题是不能把多核都吃满。天生的单线程, 虽然有 worker simd 。如果是手机端原生应用，至少可以把性能吃满。web 做的话，性能太差了。

上了个 -preset ultrafast, 一下子从 1x 变成 11x 了。不过这画质是不用看了

@wnpllrzodiac 移动端风险那么高啊 感谢预警 现在的情况是客户有时候会发 500m 以上的超大视频 如果客户发给业务人员 那业务会通过后台上传 只需要在上传之前压缩一下 功能比较简单 应该不太容易导致报错 主要是压缩时长 业务那边卡的比较死 "客户本来就不爽了 你传个视频要十分钟是想吃投诉吗😂?" 今年降本增效整的服务器资源很紧张 所以才考虑的前端方案 之后测试结果不理想的话再考虑服务器/第三方方案吧

我甚至没看懂你们的需求,什么叫预压缩,上传个视频先压缩一遍,服务器里拿到压缩好的再压一遍? 又要求质量又要求时间可太天才了, 先把提需求的打一顿吧

@paopjian 上传之前压缩一下 服务器端会利用闲置资源压缩

不如换个思路，去掉手动压缩步骤，先接纳、保存原始视频文件，等到闲时（比如下班后、半夜）再执行批量转换、压缩，替换掉这些视频文件

这个。。。官方都已经告诉你会比原版慢 10x-20x 了。。。 坛子里要能给你解决那岂不是这项目有点。。。 你现在参数视频和音频流都是直接复制，换句话讲只是解一下流然后重新打包都超时了。。。 救不动，完全救不动。。。

换个思路，一边压缩一边上传

这方面可以参考国内大厂的做法，尤其是 b 站早就把 ffmpeg 封装成 wasm 在前端使用了 https://mp.weixin.qq.com/s?__biz=Mzg3Njc0NTgwMg==&mid=2247501641&idx=1&sn=67dbbe7ae0e85ca82d4f4527f30993fe