c++高性能264/265实时流媒体服务器/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开发框架，用新技术撬动原本只属于大公司的机会。