前端上传的时候需要预压缩 希望 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"
]
1
wnpllrzodiac 6 天前 via Android
能上 webgpu 就好了
|
2
wnpllrzodiac 6 天前 via Android
能给个 baseline 测试视频么?我的机器 32 核的试试
|
3
mightybruce 6 天前
ffmpeg 是支持 gpu 加速的,不过 wasm 可能不支持, 可以试试 simd 内联函数。
|
4
mumbler 6 天前
机器什么配置,1 核 1G 怎么优化也不会快
|
5
jim9606 6 天前 via Android
wasm 目前没辙,只能用 cpu 跑。
js 可以使用 WebCodecs API,可以用上平台的编码器(机会用上硬件编码,浏览器决定),也能指定码率控制方法 减帧按我理解是不能用 bsf 实现的。 |
7
janus77 6 天前
注意到你说的是”预压缩“
有没有可能,去掉预压缩,直接在需要的时候执行压缩,但是用的不是 wasm 而是原生程序,你说了原生速度非常快,这样总消耗时间加起来反而比你现在 wasm+预压缩快? |
8
v423 OP |
9
v423 OP |
10
wnpllrzodiac 6 天前 1
@v423 移动端别指望了。肯定是上传服务端稳定。转码出了问题,你都没办法跟踪,因为片源在用户手机上。以前有个项目,要把手机上拍摄的几段片子和其他预制素材合成一个短视频。领导天真的说,要把转码放在用户手机上做。结果各种问题,用户下载预制素材都会下载失败,结果转码失败。完全没法跟踪。而且用户的低端手机转码速度完全不可控,导致用户体验完全不一致。
|
11
wnpllrzodiac 6 天前 1
试了下我的电脑,720p 视频转 2m720p 输出,只有 1x 的速度。所以一分钟就要等 1 分钟。手机上也好不到哪里。
web+wasm 页面的问题是不能把多核都吃满。天生的单线程, 虽然有 worker simd 。如果是手机端原生应用,至少可以把性能吃满。web 做的话,性能太差了。 |
12
wnpllrzodiac 6 天前
上了个 -preset ultrafast, 一下子从 1x 变成 11x 了。不过这画质是不用看了
|
13
v423 OP @wnpllrzodiac
移动端风险那么高啊 感谢预警 现在的情况是客户有时候会发 500m 以上的超大视频 如果客户发给业务人员 那业务会通过后台上传 只需要在上传之前压缩一下 功能比较简单 应该不太容易导致报错 主要是压缩时长 业务那边卡的比较死 "客户本来就不爽了 你传个视频要十分钟是想吃投诉吗😂?" 今年降本增效整的服务器资源很紧张 所以才考虑的前端方案 之后测试结果不理想的话再考虑服务器/第三方方案吧 |
14
paopjian 6 天前
我甚至没看懂你们的需求,什么叫预压缩,上传个视频先压缩一遍,服务器里拿到压缩好的再压一遍? 又要求质量又要求时间可太天才了, 先把提需求的打一顿吧
|
16
cnbatch 6 天前 2
不如换个思路,去掉手动压缩步骤,先接纳、保存原始视频文件,等到闲时(比如下班后、半夜)再执行批量转换、压缩,替换掉这些视频文件
|
17
ntedshen 6 天前
这个。。。官方都已经告诉你会比原版慢 10x-20x 了。。。
坛子里要能给你解决那岂不是这项目有点。。。 你现在参数视频和音频流都是直接复制,换句话讲只是解一下流然后重新打包都超时了。。。 救不动,完全救不动。。。 |
18
HannibaI 6 天前
换个思路,一边压缩一边上传
|
19
mightybruce 6 天前
这方面可以参考国内大厂的做法,尤其是 b 站早就把 ffmpeg 封装成 wasm 在前端使用了
https://mp.weixin.qq.com/s?__biz=Mzg3Njc0NTgwMg==&mid=2247501641&idx=1&sn=67dbbe7ae0e85ca82d4f4527f30993fe |
20
chesha1 6 天前
如果根据你的参数看,保持-c:v copy -c:a copy 的话,是起不到压缩效果的吧?似乎这么做只能转换封装格式。而且这两个参数不需要 ffmpeg 重新编码,跑得也应该飞快才对,speed 至少应该有几百倍
ffmpeg.wasm 和本地的 ffmpeg 行为差别这么大吗 |
21
1039460820 6 天前
压的太快,分辨率就要降下来
|
22
mxT52CRuqR6o5 6 天前 via Android
@mightybruce b 站是用 ffmpeg 解码选一些关键帧来在前端选封面的(不然就得等视频传完才能选封面),不是用来转码的
|
23
kujou 6 天前
追求速度视频流可以用 nvenc 编码 hevc (使用 gpu ),音频流随意(可以 LCAAC 也可以 HEAACv2 ,最后 ffmpeg 混流封装。
如果单纯 cpu 编码,速度和性价比永远是反比的,就看你自己了。不过 cpu 压是慢一些。 |
24
soul11201 6 天前 via Android
不就是上传时间影响用户体验了吗,这个简单,🚫限制上传视频大小为 5M ,让制造问题得人去解决问题,问题不分分钟解决了吗😄😄😄
|
25
soul11201 6 天前 via Android
一直感觉微信聊天中发的视频压缩做的很不错,不知道有没有大佬能科普下里面怎么做的权衡。
|
26
whi147 6 天前 via iPhone
webcodec
|
27
wzy44944 6 天前
只是上传慢的话为啥不在上传速度上想想办法,客户端压缩即使做出来了一版维护成本也太高了。实在想压缩不如给业务提供个 pc 端小工具让他们自行压缩下再上传(其实可以用微信上传给自己再下载下来)
|
28
duanxianze 6 天前
@soul11201 手机可以调用 soc 视频编解码模块,性能比纯浏览器 cpu 计算强太多了
|
29
ETiV 6 天前 via iPhone
从安全上讲,客户端预压缩、再上传等于是有手段可以绕过压缩直接上传,其实是违背了后端不信任任何前端发过来的数据的核心宗旨
最好不要有这种方案 |
30
lbp0200 6 天前
上传到云端,让云厂商来压缩
CPU 压缩视频就是这么慢,不用想了 |
31
zuotun 6 天前
Web 基本上别指望了,能用就不错了。要么直接原封不动上传到某个高速存储然后服务器再去处理,要么要求客户端装个小工具,浏览器里想办法调用这个外部工具靠硬件加速转码,我这就是这样做的,而且简单粗暴就是监听一个本地端口实现通信。
|
32
hefish 6 天前
自己开发一套基于 js 的 ffmpeg 吧,就叫他 jsmpeg 。。。。明天发布测试版。。
|
33
mrtctl 6 天前
|
34
llsquaer 5 天前
@soul11201 你让我想起了 给小娃报名。需要证件的照片,房产照片,户口本等。总共 6 张照片去传。结果教育局的网站只有一个 input button 。也就是说只能传一张图。
这些还难不倒我。开一个在线 ps ,把所有照片拼在一起,ok 。 你以为传完了? 传的时候发现只能传 1M 还是 2M 以下。有点忘了。 好像也没啥问题,在线压缩下。 结果死活差那么 100kb 左右的压不下去。 最后没法了,重新编辑下排版,尽量的缩小画布尺寸还得保持看得清。上面流程在走一遍。 --------------------------- 我怀疑差不多就是用了你的思路,难道是你徒弟? |
35
a1248499257 5 天前
之前尝试过 ffmpeg.wasm 在 web 端裁剪视频 + 压缩,但是在 ios 15 因为 simd 不兼容(好像),还是放弃了这个方案,放到服务端去操作
|