前端上传的时候需要预压缩
希望 1 分钟的视频压缩时间能控制在 1 分钟以内, 同时保证画面清晰不能有马赛克, 压缩后视频在 720p 以上 码率 2000k 以上
现在的方案是通过 ffmpeg.wasm 压缩, 官方测试结果比原生 ffmpeg 慢 10-20 倍
项目中测试只要涉及画面转码都是严重超过 1 分钟
退而求其次尝试维持视频流只减帧, 但是维持原视频流需要 copy 参数, 此时无法通过-r 设置参数, filter 只是过滤器无法压缩视频体积
昨天找了一下午没找到可用的参数, 只能请教大佬了
参数如下
const args = [
"-i",
"input.mov",
"-preset",
"ultrafast",
"-c:a",
"copy",
"-c:v",
"copy",
"-r", "24",
"output.mp4"
]

能上 webgpu 就好了

能给个 baseline 测试视频么？我的机器 32 核的试试

ffmpeg 是支持 gpu 加速的，不过 wasm 可能不支持, 可以试试 simd 内联函数。

机器什么配置，1 核 1G 怎么优化也不会快

wasm 目前没辙，只能用 cpu 跑。
js 可以使用 WebCodecs API,可以用上平台的编码器(机会用上硬件编码，浏览器决定)，也能指定码率控制方法
减帧按我理解是不能用 bsf 实现的。

普通 pc
客户或者内部员工上传的时候使用 硬件不会特别差

主要平台是 web 前端 没法跑原生 这个运行效率太低了

注意到你说的是”预压缩“
有没有可能，去掉预压缩，直接在需要的时候执行压缩，但是用的不是 wasm 而是原生程序，你说了原生速度非常快，这样总消耗时间加起来反而比你现在 wasm+预压缩快？

感谢回复
不过这是个通用性的上传组件 对内对外的表单都会用到
所以测试主要考虑中低性能的机型
产品那边期望移动端也能达到这个压缩效率(现在看看是有点异想天开了

抱歉写的有点歧义 前面想改但是没找到在哪贴条
前端指的是 web 端 这是在表单上传视频的时候触发的预处理
原生 ffmpeg 是基于 c/c++的, web 端调用不了啦

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

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

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

移动端风险那么高啊 感谢预警

现在的情况是客户有时候会发 500m 以上的超大视频 如果客户发给业务人员 那业务会通过后台上传
只需要在上传之前压缩一下 功能比较简单 应该不太容易导致报错
主要是压缩时长 业务那边卡的比较死
"客户本来就不爽了 你传个视频要十分钟是想吃投诉吗😂?"

今年降本增效整的服务器资源很紧张 所以才考虑的前端方案
之后测试结果不理想的话再考虑服务器/第三方方案吧

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

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

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

这个。。。官方都已经告诉你会比原版慢 10x-20x 了。。。
坛子里要能给你解决那岂不是这项目有点。。。

你现在参数视频和音频流都是直接复制，换句话讲只是解一下流然后重新打包都超时了。。。
救不动，完全救不动。。。

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

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

如果根据你的参数看，保持-c:v copy -c:a copy 的话，是起不到压缩效果的吧？似乎这么做只能转换封装格式。而且这两个参数不需要 ffmpeg 重新编码，跑得也应该飞快才对，speed 至少应该有几百倍

ffmpeg.wasm 和本地的 ffmpeg 行为差别这么大吗

压的太快，分辨率就要降下来

b 站是用 ffmpeg 解码选一些关键帧来在前端选封面的(不然就得等视频传完才能选封面)，不是用来转码的

追求速度视频流可以用 nvenc 编码 hevc （使用 gpu ），音频流随意（可以 LCAAC 也可以 HEAACv2 ，最后 ffmpeg 混流封装。
如果单纯 cpu 编码，速度和性价比永远是反比的，就看你自己了。不过 cpu 压是慢一些。

不就是上传时间影响用户体验了吗，这个简单，🚫限制上传视频大小为 5M ，让制造问题得人去解决问题，问题不分分钟解决了吗😄😄😄

一直感觉微信聊天中发的视频压缩做的很不错，不知道有没有大佬能科普下里面怎么做的权衡。

webcodec

只是上传慢的话为啥不在上传速度上想想办法，客户端压缩即使做出来了一版维护成本也太高了。实在想压缩不如给业务提供个 pc 端小工具让他们自行压缩下再上传（其实可以用微信上传给自己再下载下来）

手机可以调用 soc 视频编解码模块，性能比纯浏览器 cpu 计算强太多了

从安全上讲，客户端预压缩、再上传等于是有手段可以绕过压缩直接上传，其实是违背了后端不信任任何前端发过来的数据的核心宗旨

最好不要有这种方案

上传到云端，让云厂商来压缩
CPU 压缩视频就是这么慢，不用想了

Web 基本上别指望了，能用就不错了。要么直接原封不动上传到某个高速存储然后服务器再去处理，要么要求客户端装个小工具，浏览器里想办法调用这个外部工具靠硬件加速转码，我这就是这样做的，而且简单粗暴就是监听一个本地端口实现通信。

自己开发一套基于 js 的 ffmpeg 吧，就叫他 jsmpeg 。。。。明天发布测试版。。

1. “维持原视频流” 和 “减帧” 从原理上就无法实现：几乎在所有的现代编码格式里，帧间压缩都是核心内容。也就是说帧和帧并不是独立的，没有办法在直接“减掉某一帧”的情况下正常解码其他帧。

2. 720p 实时（ 1 分钟转码 1 分钟的视频）的视频转码就算是纯 CPU 编码也不是很大的性能负担。前端编码的话可以看看上面说的 WebCodecs 。
3. 如果一定要用 ffmpeg.wasm ，试了一下编码 720p 1 分钟视频，单线程 30 秒内，多线程不到 5 秒就可以完成编码（ Safari @ M2 Pro ）。应该也算可用的？