系列文章：
音视频:H.264 与 H.265 编码
一 简介
上一篇已经介绍了H.264和H.265之间的一些关系和基础，简单来说，H.265标准围绕着视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。
改进点包括：提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。H.264可以低于1Mbps的速度实现标清（分辨率在1280P720以下）数字图像传送；而H.265则可以实现利用1~2Mbps的传输速度传送720P（分辨率1280720）普通高清音视频传送。
更多二者之间的差异，也可以查看H.265与H.264的差异详解这篇文章做个了解。
二 H.265视频播放
2.1 H.265带来的问题
对于我们来说，编码技术的优化是好的，但功能的实现更加重要。例如，已经接入过H.264的设备，要新接一些H.265的设备，必然会带来两个问题：一是怎样接入（播放）；二是怎样做好兼容。本篇我们先只考虑第一个问题，即怎样实现H.265视频的播放？
2.2 视频播放器典型架构
通常播放器都是由播放器内核 和 UI界面组成。再做细分，播放器内核还包括 解码器、多媒体引擎等；UI包括UI组件、业务逻辑模块。
如果从数据流的角度来讲，播放器所起的作用包括读取、解析。渲染音视频文件，涉及的模块和数据流转过程如下：
- 其中，source是指多媒体数据流，来源于网络或本地文件；
- demux是解复用器/解服用模块，媒体文件和网络流是将音视频压缩编码后和其他数据一起打包传输的，解封装与上述过程正好相反，是将音视频流做分离处理。支持的常见格式，包括mp4，flv，m3u8，avi等等；
- decoder是解码器，上面的两个分支分别是音频解码器和视频解码器；解码器其实也属于数据解析的一种，只不过更多的是负责对压缩的音视频数据进行解码，拿到原始的 YUV 和 PCM 数据，常见的视频压缩格式如：H.264、MPEG4、VP8/VP9，音频压缩格式如 G.711、AAC、Speex 等
- video sink是视频渲染显示模块，音频是声卡等。这一层也可以理解为渲染层，即负责视频数据的绘制和渲染。不同的平台有不同的渲染 API 和方法，比如：Windows 的 DDraw/DirectSound，Android 的 SurfaceView/AudioTrack，跨平台的如：OpenGL 和 ALSA 等。
三 H.265播放方案
3.1 编解码支持
大家使用H5方案播放mp4或m3u8的时候，可能主要还是使用现成的组件，所以没有特别关注过编解码的问题。可以直接h5播放（不直接或者间接使用flash插件）的方案，大部分支持的都是H.264编码的视频；当我们要播放H.265的时候，就必须要对编解码有些认识了。
3.2 H.265的硬解码与软解码
解码方式，根据使用软件 or 硬件 能力，可以区分为软解（即软件解码）和硬解（硬件解码）两类。
操作系统借助硬件(显卡)进行H.265编码视频的解码工作，其好处是硬解的功耗低，解码速度快。但目前H.265编码在浏览器中的硬件解码支持情况并不普及。而且，硬件解码需要用户的显卡支持H.265 codec, 在之前的显卡中并不能保证都可以支持。
软解方案，也可以分为两种，一种是基于Flash的H.265解码方案，即通过FlasCC编译器把C语言编写的解码器编译成swc库，然后在Flash播放器中用Action Script调用swc库；另一种就是纯H5方案，使用WebAssembly技术将金山云自研的高性能解码器编译为wasm库，wasm文件是以二进制形式存在的，其中包含平台无关的虚拟指令（类似汇编指令）。这也是很多移动平台采用的方案。
3.3 经验与思考
考虑到浏览器逐渐不再支持flash插件，纯H5的方案会是以后更多的选择。但至少截至目前，H5播放也还存在着比较严重的性能问题。因为解码是需要消耗大量资源的，或是GPU，或是CPU。目前的H5方案，在某小伙伴的机器上进行测试，播放H.265视频时，CPU占用超过了100%，而且是i系列较高配置的机器，可见如果放在一般的机器上运行，很可能会出现丢帧、卡顿等影响体验的问题，所以目前一个临时方案是对H.265在后端进行转码，转成H.264格式之后再做播放，以减轻前端的资源压力。
3.4 h265播放器
推荐一个h265播放器，是github上开源的工程，即goldvideo的h265player，目前正在试用。感兴趣的朋友们可以进行尝试，https://github.com/goldvideo/h265player。
