文章目录
- c++高性能264/265实时流媒体服务器/h5客户端整体解决方案源码
- 缘由
- 目前的前端技术栈,已经能够支撑常规的安防桌面客户端软件开发
- 我的方案
- 一套c++后端,两套前端
- H5 UI方案一:多屏h265/h264混合显示
- H5 UI方案二:H5监控大屏,提供视图切换功能
- 优点
- 总结
c++高性能264/265实时流媒体服务器/h5客户端整体解决方案源码
缘由
长期以来chrome一直致力于推广自己的vp9解码,而不支持h265, 而互联网上有大量的h265视频,事实上,安防行业自2019年就有大量的h265产品了,推动的理由很简单:更高的编码复杂度,同样的清晰度有着更低的码率,这样可以大幅度降低存储成本。
在此之前,chrome支持fmp4流媒体播放h264但不支持h265。这就催生了大量临时方案
-
wasm方案的h265解码器,他们不辞辛苦的将ffmpeg编译成wasm,然后利用js调用cpu来解码h265视频。这样的方案依赖CPU软解,能用但性能不足,典型情况下,在普通PC机上只能够播放一路1080p的h265视频
-
修改chrome源码,重新编译ffmpeg,使其支持265解码,这个效果比wasm更好,也有可能做到一定程度的GPU硬件加速,但硬件适配远没有chrome做的更好,毕竟chrome面临的是这个世界上绝大多数的桌面端、移动端设备。
目前的前端技术栈,已经能够支撑常规的安防桌面客户端软件开发
前端的优势:
- 绝佳的UI表现能力;
- 面向新需求快速开发的能力;
- 前后端分开,容易搭建团队的能力;
可以说上面的几个优点,招招都踢在传统桌面客户端的要害上。
我的方案
主要分为两块,
- 后端流媒体服务
- 两个前端UI
整体逻辑如下:
一套c++后端,两套前端
H5 UI方案一:多屏h265/h264混合显示
主要逻辑:前端查询后端可用的流列表,流式布局显示,点击播放
后端提供多个测试文件,前端就会展示相应的个数,快速帮助使用者摸清播放性能边界。
打开后查询对应的流个数
本例中,后端提供5路流,点击播放后
图中附上任务管理器截图,可以看到CPU和GPU使用量
H5 UI方案二:H5监控大屏,提供视图切换功能
此方案值得一提的是:
- 提供1分屏、4分屏、8分屏、9分屏、16分屏、32分屏、64分屏切换;
- 分屏切换不会停止播放;
优点
-
GPU解码,无插件,chrome网页播放32路 h256/hevc 直播视频流,毫无压力;
-
纯c++编写,可以运行在绝大多数嵌入式、x86环境下, 只要c++版本不低于14;
-
基于h5原始“video”标签,方便集成到自己的前端项目中;
-
白盒交付,提供前后端全部源码;
总结
前端视频应用的机会已经到来,小公司可以掌握更多的机会,用前端开发去替代原先的qt等传统UI开发框架,用新技术撬动原本只属于大公司的机会。