瑞芯微rk3568移植openbmc（五）----关于novnc h265 webcodec硬解码
本章没有什么实质内容，其实在第四节调好了H264的webcodec以后，H265仅仅只需要改下参数，其他的都交给webgl去处理就行了，没有什么大的变化，vp8、vp9、h264、h265处理都一样，仅仅只是参数的变化，不得不说谷歌浏览器做的确实让开发人员用起来很舒服。
下面简单说明一下H264和H265的配置：webcodec的示例代码如下：
webcodecs/main.js at main · w3c/webcodecs · GitHub
这几个参数有部分是固定的，如H264中avc1.就是固定不变的，后面的42002A实际上是H264中配置的profile和level的值，如果确实不清楚自己配置的多少也没关系，通常这个值存在H264的SPS的NAL单元中（一般都是首帧），抓取一帧H264的流就清楚了，如下图所示：00 00 00 01表示一帧的开始，67表示此帧为SPS帧，紧接着的42 C0 2A即表示profile和level了，上述webcodec的参数改为此值就行：avc1.42c02a
而H265中就复杂了，目前尚未完全搞懂H265的参数结构。以下讲述仅供参考，如有大佬能解惑不胜感激。H265的参数值表示方式和H264完全不同，其表示Profile.Flags.TierLevel.Constraints，比H264多了一个VPS NAL，而webcodec的参数信息就存在于VPS当中，H265的webcodec前缀可以为hev1或hvc1，以一帧H265为例：帧头仍为00 00 00 01, 40表示当前是一帧VPS NAL单元，01表示当前是main profile，如果是02则表示main 10 profile，78表示TierLevel为120
如果以命令：ffprobe -v quiet -print_format json -show_streams 1.h265 查询当前帧的信息可以看到：profile为Main，level为120，Flags即为has_b_frames：0，组合起来即为：hvc1.1.0.L120.xx或hvc1.1.0.H120.xx，具体更详细的信息目前尚不清楚，本人只能靠实际环境来调试了，目前测试配置为hvc1.1.0.L120.00或hvc1.1.0.L120均可以正常解码
{"streams": [{"index": 0,"codec_name": "hevc","codec_long_name": "H.265 / HEVC (High Efficiency Video Coding)","profile": "Main","codec_type": "video","codec_time_base": "1/30","codec_tag_string": "[0][0][0][0]","codec_tag": "0x0000","width": 1920,"height": 1080,"coded_width": 1920,"coded_height": 1080,"closed_captions": 0,"has_b_frames": 0,"pix_fmt": "yuv420p","level": 120,"color_range": "tv","refs": 1,"r_frame_rate": "30/1","avg_frame_rate": "30/1","time_base": "1/1200000","disposition": {"default": 0,"dub": 0,"original": 0,"comment": 0,"lyrics": 0,"karaoke": 0,"forced": 0,"hearing_impaired": 0,"visual_impaired": 0,"clean_effects": 0,"attached_pic": 0,"timed_thumbnails": 0}}]
}实测H264与H265硬解不管是从代码修改上，还是清晰度异或是帧率上都没有太大区别，仅仅只是H265比H264稍稍省一点点带宽而已，协议理论上H265比H264能省30%~40%，实际测试起来也就10%左右的差距，对应VNC应用来说这点流量差距几乎可以忽略，因H264和JPEG Tight编码比起来本身已经是非常非常省流量了，H265相对于H264省的流量比起JPEG Tight编码那就可以几乎忽略不计