瑞芯微rk3568移植openbmc（三）----关于novnc h264 webassembly软解码

2022.11.04 更新

1、关于h264 novnc 软解码

   openbmc中使用的ipkvm其server端调用的是libvncserver库，而其web client端调用的则是novnc的库，既上篇研究修改了libvncserver后，再次继续研究了一下novnc。

        Github搜索一圈以后，发现https://github.com/martin19/noVNC 此项目基于树莓派开发板，作者fork了原始novnc工程，添加修改的H264的novnc解码器，于是笔者fork了该作者的工程，基于该工程之上适配了rk3568的H264相关工作，修改了该工程的H264协议定义，按此open H264制定的协议规范对libvncserver和novnc两端进行了调整：https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#open-h-264-encoding 

先是在novnc的环境中把h264解码调试ok

 再将novnc打包成库，集成到了openbmc当中：

     1080P分辨率下对比了一下H264编码占用的带宽（上图），以及JPEG Tight编码占用的带宽（下图），确实在清晰度差不多的情况下，H264编码带宽仅有JPEG Tight的1/4左右，如果是静止不动的桌面，H264几乎没有什么流量，B帧传输期间，流量在几十Kbps，I帧时2Mbps左右，而JPEG Tight编码即便在桌面静止不动的情况下占用带宽依然为20Mbps左右。

         尽管把H264添加到了novnc中，实际测试确实省流量带宽，但仍然存在不少问题：

        如直接使用TigerVNC连接BMC VNC服务器时，帧率最高可以接近50帧，平均帧率在45左右，且此帧率下带宽占用也仅有10Mbps，但使用novnc后，因novnc需要将bmc上的VNC TCP port 5900转为websocket与novnc web的客户端通信，中间多了一层数据转发，使得novnc帧率直线下降，实际测试中novnc下无论是H264编码还是JPEG的Tight编码，帧率仅在15~25之间浮动，H264编码的性能直接被拉低到与JPEG Tight编码相差无几。

       相信novnc和websocket方面优化一下，性能上H264肯定还能再提升一点点，但是这个优化起来难度就相对高了。novnc的软解研究就先到这里吧，后续有时间再来考虑相关优化。