程序员菜鸟,请教一个 web 视频转码的问题

104 天前
 Asuler
我们公司在某地硬件设备上装了视频监控,目前是上传到云存储桶里,为了节省存储带宽等成本,存的是 h.265 编码格式的视频,但是这样子在浏览器端没法播放

所以我想了两个方案
1. 浏览器端找能支持 h265 的播放器 js ,但是基本上找到的都是基于 wasm 的 ffmpeg ,也就是在浏览器端解码,然后通过 canvas 一帧一帧画,然后再用 audio 播放声音。感觉这个方案不是很好,可能会又吃性能又卡,还有可能声音画面不同步。

2.通过增加中间层服务,使用 ffmpeg+nodejs 进行转码(我不太会其他语言)。尝试了一下如果用 ffmpeg 完全把一个视频转换成 h264 的格式,耗费的时间会很长,有些长视频要半个多小时。

所以我现在的想法是:

我看浏览器的 video 标签加载视频时,也不是整个视频缓冲完才开始播放呀,metadata 加载到了就可以播放了?而且貌似也是播放一点加载一点,这样是不是可以用 ffmpeg+nodejs 做成实时转码的服务?浏览器端请求一小段,就转一小段,这样子就使得该视频原生支持 video 标签了,也不需要额外的播放器 js 了。同时也能使用 video 标签自带的进度条拖拽进度

想问下大家我的这个想法是否可行?

还有个问题,我看到一些方案里写 ffmpeg 转 m3u8 ,然后存一堆 ts 文件,浏览器端再用某个 js 播放库去播放,这样存储成本是不是又上来了?外加转码服务的服务器成本,搞不好还不如一开始直接存 h264 格式?

ffmpeg+nodejs 有没有可能做到实时转码成原生 video 支持的格式,对于浏览器端来说属于无感知的转码那种的,不需要存文件,直接返回流给前端
2116 次点击
所在节点    程序员
21 条回复
zhmouV2
104 天前
第一个性能确实挺烂的,俺任职的某个小公司似乎有个平台也是这么实现的(斜眼笑
但是 chrome 现在不是可以 h265 硬解吗?具体我也不是很懂
beyondsoft
104 天前
你这样性能太低了, 如果同时有多个人怎么解决. 我给你推荐一个方案 用一个中间服务, 中间服务自己把 视频流录制好, 页面里面直接引用就好. 在这里强烈推荐
https://github.com/bluenviron/mediamtx 这个项目, 部署一下然后把监控的流推到这里, 页面直接用就行了
rabbbit
104 天前
给一个实现方式参考,挺邪门的。
海康的 web sdk 自带支持查看录像机的 h265 回放(需要本地安装 exe 软件)。
猜测原理是 exe 开个服务,本地解码 h265 ,绘制一个窗口盖在浏览器上。
kk2syc
104 天前
sagaxu
104 天前
建议好好研究研究几个 porn 视频网站,看看业界是怎么存储和播放的
z0ffy
104 天前
chrome105 之后支持硬解。应该可以支持大部分 h265 。再用 electron 搞个播放端,解决。剩余播放不了的,丢过去转码。
ysc3839
104 天前
实时转码一般也会存入硬盘的,不然内存消耗很大
xiaohang427
104 天前
@sagaxu 思路刁钻
Projection
104 天前
https://chromium.woolyss.com/ 有包含 H.265 解码器的 Chromium 下载
为哈非得在浏览器播放,本地随便起个播放器不行吗
lingo
104 天前
我们之前是直播流,rtsp 还是 rtmp 什么的细节忘了。。内部用的,大佬直接改了 chromium 的源码(笑哭
billlee
104 天前
看看 b 站是怎么做的,他们可以 wasm 软解 av1
geekvcn
104 天前
你用的啥野鸡浏览器? Edge ? Edge 去商店装个 HEVC 扩展,Chrome 的话字节跳动早就提交代码支持 HEVC 解码了 107 之后的版本
qqqnnn
104 天前
h265 本身电脑都支持硬解 看看是否装了 hevc 可以看看常用的 web 播放器 flv-h264js xgplay jessibuca
jifengg
104 天前
前段时间一个项目参考过 https://github.com/648540858/wvp-GB28181-pro
这个项目,他支持页面播放 h265 的,可以自己研究一下。
rain0002009
104 天前
既然都云存储了 为啥不用云存储提供的服务 不管是阿里云,百度云啥的一般都提供音视频转码和视频播放 sdk 就是要钱
heimoshuiyu
104 天前
> ffmpeg+nodejs 有没有可能做到实时转码成原生 video 支持的格式,对于浏览器端来说属于无感知的转码那种的,不需要存文件,直接返回流给前端

可以,我在自己的项目里 https://github.com/heimoshuiyu/msw-open-music 就这么做的,后端调用 ffmpeg 数据输出到标准输出流,然后直接发送到浏览器。我还注意到其他项目也是这样实现的实时转码
- https://github.com/jellyfin/jellyfin
- https://github.com/sentriz/gonic

不过这么做不支持 seek 播放,需要后端根据客户端请求播放的视频时间点,修改 ffmpeg 的 -ss 参数
janus77
104 天前
不用搞这么复杂,很简单,首先回放做本地磁盘缓存+云端同步,近期的就直接从本地磁盘播,要看很久以前的回放,再去拉云端资源,这个情况占比较少,所以带宽方面并不占太多,云端储存的话本身就便宜,而且冷数据会更便宜。
中间件实时转码的话,首先你这个中间件配置不能太低,如果有多个用户同时看不同的视频,那你的机器同时实时解码多个流,性能能否吃的住?并且也一样占用带宽,我不知道从数据服务器接收数据算不算带宽,如果算的话,接收数据+转码以后回传到你的播放端,算是两倍带宽成本了。
nevermoreluo
104 天前
你要问可行不可行,只要时间够,应该都是可行的
不过我还是建议,试试找找监控厂家是不是有现成方案

或者试试一些 github 是现成的流媒体服务器,看看能不能客户端实现对应 api 做拉流就行了,省的自己写一大堆坑。流媒体水太深了,video 标签不支持的格式,为什么不支持拉出来可以研究一下午。
DOLLOR
104 天前
能不能说下视频编码的具体参数?按道理现在的 chrome 都能正常直接播放 h265/hevc 了。
twosix
104 天前

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1070574

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX