摘要
2020年10月21-22日，以【逆向·生长】为主题的第八届亚太内容分发大会·北京站隆重拉开帷幕。历经2020年特大疫情之后，传统经济遭受到巨大的冲击，而以视频、游戏、电商、教育、金融为主的互联网领域经济却带来飞速发展机会。
如何利用边缘计算、融合创新等技术降低国内CDN成本，如何把握当下所衍生的时间窗口、创新技术对视频分发的影响以及技术开放对视频分发的增益等问题成为本届大会的焦点。
在10月21日下午举办的“边缘计算论坛”上，SynaMedia中国区CDN和云业务负责人梁峰以《低延时编码助力CDN快速分发》为主题，分享了SynaMedia在低延时编码方面的创新举措。
未来中国CDN市场会有很大的增长，预计到2022年，中国CDN市场规模会增长到298亿。此外，近年来手机、电脑、电视等终端之间的跨平台需求也在不断增长。作为CDN供应商，要能做到在不断增长的需求基础上，快速地做内容的分发。
根据调研结果显示，视频受众的需求集中在三个维度：用户体验、低延时、大规模的扩展。三个维度上对CDN技术，包括视频编解码的技术提出了新的挑战，厂商需要权衡低延时、用户体验和高扩展性。业界正在向前探索发展，对于低延时可以用RTC或者RTMP这类实时交互协议，但是RTC、RTMP对传统CDN的要求较高，在一般公网CDN和私网CDN上，大多数CDN厂商用HTTP协议做传输，绝大多数CDN的厂商都能够做到HTTP1.1的分片传输；但要以支持WebRTC和RTMP的方式做内容分发，普遍性就不高了，而且WebRTC以及RTMP对带宽和成本的要求比较高。怎样基于HTTP的方式去分享，却能够达到类似于WebRTC或者RTMP的低延时效果，这是我们所要面对的问题。
另外一种常用的HLS/DASH协议非常通用，也很容易扩展，但是实时性非常差，由于分片的原因，很难满足用户对实时性要求比较高的场景。我们需要的是低延时、大规模扩展和用户体验三者都能兼顾到，而不是只能兼顾到其中的一两个因素。
我们希望的目标是能够做到亚秒级的延时，HLS和DASH的标准分片在6到10秒区间，它的延时一般在10到30秒，这样的延时对于用户观看普通的电视剧是没有问题的，但满足不了用户对于赛事类直播的观看需求。为了解决低延时Apple最新发布了低延时HLS即LL-HLS，MPEG组织也发布了LL-DASH，这些规范依然是基于HTTP的分片传输，即使是这样也是只能做到1到2秒的延时。
下一代的协议，必须要兼顾到用户体验、低延时以及可扩展性，要能做到和通过广播网在家中看直播电视同样体验的效果。为此，Synamedia和THEO成立了HESP联盟，提出了HESP协议，即高效视频流化协议。这是一项基于HTTP新的传输的流化协议，采用HESP协议可以达到亚秒级的延时，同时可以做到对整个编码的GOP的长度设置的非常长，这样编码的效率就会提高，带宽节约20%以上。最主要的是该协议对于现有的CDN基础设施并没有提出更加高的要求，依然可以用分片传输的方式达到亚秒级传输的效果，所可扩展性是非常好。用户的体验也非常棒，用户可以得到非常快速的播出响应，另外频道切换、画面切换的速度也是非常好。
这是流化协议简单的演示，编码器会生成两个视频流，两条流时钟严格对齐。一条流叫做基础流，编码中只有IDR帧，另一条流叫做连续流，编码的GOP可以设置到20秒的长度。HESP封装服务会把两条流打包成一条基于帧分片的视频流，每一个分片仅包含一帧图像。终端播放器请求播放一个直播频道时，基础流的IDR帧会被首先传送，然后再把连续流对应的B帧或者P帧的分片数据传输给播放器，这样播放器就可以立刻从IDR帧开始播放，没有任何延迟。平均来说播放器大部分时间是在播放连续流，也就是GOP的大小可以非常长的视频流，而GOP长度越长它的编码效率就会越高，使得带宽使用可以节约大概20%左右。
HESP和现在业界其他的一些传输方式比较，在低延时方面与WebRTC、RTMP可以达到同样的效果，而带宽的要求远远低于WebRTC和RTMP，在通用性方面还是基于HTTP1.1分片传输的方式，可以做到多码率、自适应码率的传送。在切换时间方面，速度相当于观看电视的切换一样，对比HLS和WebRTC有非常明显的优势。
通过研究发现，HESP高效流化协议这项新定义的基于HTTP的协议，是把大屏搬上互联网优秀方式，目前基于HTTP自适应的码流已经非常普遍的在很多终端上使用了，然而，对于IPTV和传送到机顶盒来说，有明显的缺点。HESP的目标是通过优化对这些平台的交付来解决这个问题，在节约带宽的同时提供低延时的直播级用户体验。
HESP定义最基本的原理就是简单化，尽可能地减少开销。第一个就是清单文件，在HLS传送和DASH传送的时候都有这样的清单文件或者索引文件，尤其是在苹果出了LL-HLS或者LL-DASH，对清单文件更新的频率的要求都是非常大的；在带宽要求上、在终端的配合和CDN配合上面都有非常高的要求。另一方面HESP是完全基于HTTP1.1 CTE传输，现在CDN的厂商完全可以满足这样的要求，这样新的协议是非常方便去扩展到现在的系统里去。第三点HESP所在技术核心点，可以生成两条互补的流，“初始化流”可以随时请求图像开始播放，“连续流”可以在任何初始化流图像后继续播放。
下面，我们来看看在整个端到端的系统里引入HESP都需要对哪些组件进行升级。首先是编码器，它需要生成两条流，初始化流和连续流，但不会带来额外带宽消耗，因为编码器总是和源站封装打包服务器一起部署在总前端，源站封装打包的服务器会把两条流合成一条流。如果你这个终端播的是第一次播放，会把初始化流的IDR帧发下去，同时会告诉终端相应的连续流的后续帧分片的HTTP的位置在哪里，再采用HTTP的方式继续下载，相当于在打包封装和终端的播放器上集成HESP协议，达到刚跟WebRTC和RTMP媲美的及时性，把带宽请求和消耗做极大的降低。一是交付少了，不需要像低延时的HLS或者DASH需要更多的额外开销，另外编码上采用更长的GOP编码方式，这样整个编码效率会大大的提升。
点击“阅读原文”回顾大会精彩内容
继续阅读
阅读原文