京东云端到端多媒体关键技术揭秘

从带来更高编码效率、更好的用户体验的京享高清，到直播架构与网络演进优化，从而为用户带来更流畅的观看体验，以及运维系统的异常自动修复和高弹性的多媒体存储架构，一层一层展示出复杂而有序的多媒体技术框架。 本文是对在LiveVideoStackCon 2019北京的京东云技术专场的内容回顾。

文 / LiveVideoStack

AI和5G分别正在和即将改变着多媒体技术生态，当然这会给用户带来更好的甚至是全新的体验。 8月23日，在LiveVideoStackCon 2019北京的京东云技术专场上，四名来自京东云的技术专家分享了京东云在多媒体技术的积累与技术突破，以及对未来5G+AI时代的展望。

? 向左滑动查看更多精彩瞬间 ?

复杂网络下底层编码技术优化提升用户体验

复杂网络条件下如何为用户带来更优质的视频观看体验，这个问题一直是音视频技术领域中的关键和难点。 对此京东云从4个方面着手提升用户体验： 从底层视频编码，“京享超清”技术提供了高质量、低成本的视频转码效果； 针对复杂网络，端到端多码率切换技术保障直播、点播视频做到无卡顿、无黑屏； 舒适音频让用户在多场景频繁切换中保持平和的听觉过渡，提升整体观看体验； 并从文件预处理做好质量检测，减少无效转码，提前预知视频缺陷。

“京享超清”

张树军认为在当下视频清晰度不断提升和网络复杂度导致的卡顿、丢包的情况下，如何做到保证相同观看质量的同时尽量降低码率是音视频技术发展的趋势和关键。 针对于高质量、低成本的视频转码，京东云在5个方面做了技术优化： 图像和视频级的去噪、锐化，针对低码率视频的插帧处理，针对用户感兴趣区域的画质增强，分类场景的编码优化以及与AI结合的视频编解码处理。

特别一提的是，通用的去噪都是针对于图像级和空域级，是在YUV和RGB上做处理，其实这种处理是对所有块都适用的，然而视频是有块属性和运动属性的，因此京东云对指定的帧类型或宏块类型的区域，结合现有的单通、双通、DCT等去噪算法做优化，实现对某一帧或宏块类型的自适应去噪。 除此以外，京东云还结合AI技术，识别、分析视频场景和用户感兴趣区域，针对不同场景和区域采取不同的编码和码率控制策略，达到在同等质量和观看体验的前提下，为用户和客户降低带宽成本。

多码率切换

面对国内用户复杂的观看网络条件和设备多样化，尤其是用户在不同网络间切换出现的网络抖动情况，很难采用统一的转码策略满足所有用户的观看体验需求。 张树军表示京东云目前采用端到端的多码率切换技术来解决这一痛点，包括点播和直播场景的多码率切换对齐。

常规的多码率切换对齐方式主要有Segment、GOP和帧级三种： Segment相对而言是最简单的IDR对齐方式，在客户端和Server端的处理最为方便，但同时也是切换速度最慢的； 相对于Segment，GOP则可以做到更精细，切换速度也更快，但由于GOP固定，有人为因素干预编码，从而导致最终质量下降； 帧级切换鉴于是逐帧编码，切换速度最快，但同时对用户终端和网络要求也会更高。 因此京东云针对点播和直播场景做了优化。

对于点播一般会做2-pass编码，第一pass数据会给第二pass数据做参考使用，而如果做多档转码输出——通过一档的mbtree数据指导其他档2-pass转码输出实现各档次帧类型和时间戳对齐，但由于是基于参考档1-pass指导2-pass转码输出，因此实际输出质量并不高。 京东云在此基础上，增加了下图紫色模块（特定YUV）保证lookahead输出的每一帧数据在多档输出统一一致。

对于直播场景可以借鉴点播的逻辑，但由于不同用户的拉流时间点不同，因此只能在场景切换后的多档直播流做到对齐，不过针对某些场景切换特别长的情况，相应对齐部分也被拉长，直接影响了用户观看体验。 京东云在直播对齐中引入了一些同步机制，在拉流过程中将同步信息加入到流中，这一操作并不会对转码效果产生影响，但收到同步信息的每条转码流可以在一个时间点插入I帧对齐，在体验和功能满足性上得到提升。

舒适音频

我们经常可以在体育赛事或者演唱会中遇到一种情况： 多个不同环境下的场景频繁切换导致音量忽高忽低，对于用户的听觉体验造成极大影响。 针对这种情况，单项增益和常规均衡化会导致原声失真、低音效果差和失去原本声音高低效果。 京东云对于多场景切换的音频，首先会做音频的整体分析，并根据自定义的舒适区判断音频是否需要动态调整使其达到较好的收听体验。

以存储为中心提升高性能、高可用、低成本直播服务

伴随视频画质和需求的不断提升，视频容量、数量的增多以及容量和带宽的弹性扩展成为视频云服务厂商面临的一大挑战。 与此同时，用户对于高画质、高流畅、无卡顿的观看需求的提升，也对低延时在线上传以及高吞吐的离线处理性能提出了更高要求，而由此带来的数据成本与数据安全问题也不容忽视。

海量视频存储系统

针对上面提到的挑战，京东云是如何做到百P级别存储服务的？ 对于一个经典模型——一个中央节点组成大目录树，下面是很多数据节点存储数据，类似于HDFS，实际上这个架构就可以满足视频存储的基本需求——视频上传、下载，但是在所承载的文件数量和容量上仍是无法满足，同时这种树形结构在磁盘访问、扩展性和中央节点管理磁盘能力上的表现并不好。 因此，京东云构建了一套基于KV结构的视频存储系统，对NameNode从功能上做简化，将目录拉平——每一个文件名对应文件数据位置，用Meta Service管理文件名到文件数据位置的映射，由此可以看作为一个有效数组存储在多个集群中，元数据通过Meta调取不同集群中的数据，这种结构也更易于扩展。 而在Data Service中，每个集群中的每个数据都对应唯一的ID（这个ID存储在元数据中），相当于一个flv文件映射为不同集群中对应ID的数据。 这种多后端集群存储还具有一个优势——针对不同类型的数据可以在不同后端进行存储，比如类似m3u8这种需要频繁访问的文件可以放在SSD集群，ts文件可以放在标准存储集群，视频的冷备份可以放在EC集群，转码的中间文件可以放到RRS集群。

以存储为中心的处理框架

对于一个视频，存储是基础，处理是目的，在京东云的数据处理框架中分为同步处理和异步处理。 同步处理——在数据下载时同步做处理，相当于用计算资源换存储资源，它适用于一些图片水印、剪裁等场景，京东云同步处理框架提供了根据请求参数调度后端服务，以及同时支持传数据和传链接两种方式的数据处理服务能力。 对于异步处理——基于存在数据离线做处理，整个异步处理框架我们是通过多个消息队列实现的——即时处理和不同时间的延时处理消息队列，由此我们可以保证至少一次的鉴黄调用以及后端服务繁忙时指数退避。

基于公有云的点播服务

对于点播或者直播服务，高吞吐、低延时的性能、高可用性以及成本优化成为了关键。 京东云基于公有云的点播服务中，用户从云主机（业务系统）请求上传链接，这个上传链接对应存储链接，用户直接通过客户端上传数据到对象存储服务，再通过异步处理机制触发业务逻辑（如转码、鉴黄），处理完成后上传到对象存储服务通过异步处理机制触发自有业务系统（如媒资管理等），最后生成链接通过CDN分发。

多核心协同拓扑CDN分发网络架构演进

视频直播不同于传统的点播和网页加速，它对延迟和卡顿更加敏感，并且具有极其明显的流量突发特点而国内网络接入的又十分复杂，除了三大运营商，还要对小运营商、教育网等做CDN优化。 下面将着重针对CDN网络架构实践、演进与性能调优方面进行讲解。

CDN网络架构演进

对于一个直播云架构而言，核心诉求集中在高可用、易扩展、高性能三方面，在这一背景下，我们首先需要挖掘单机或单节点的性能潜力。 京东云会将每个节点抽象为虚拟的两层，在节点内部的边缘上通过轮询的方式将流量打散接入，如果出现突发流量可以充分利用每个机器的能力，在流量打散后内部通过哈希汇聚到内部逻辑的二级源，再由二级源做真正的回源。 当有多路流时可以合并回源，减小回源带宽，同时有效减少它们内部的交互成本。

在充分挖掘单机及单节点潜力的基础上，我们进行CDN组网。 在最初的单核心拓扑架构实践中，我们发现存在两个问题： 首先是无法动态选路，其次核心集群只有华北地区一个，存在明显的单点问题。 因此在这个基础上我们设立了南方核心集群形成双核心协同架构，南北方核心集群通过专线连接，由此也同时实现了异地灾备，提升了整体可用性。 但这套架构存在同样的问题，也就是线路选择仍旧依靠运维经验手工配置，响应速度无法很好满足。

伴随京东云核心集群和边缘节点的不断建设扩充，京东云通过流控中心实时探测网络情况，对回源线路进行统一调度，实现二级源之间回源、二级源和其他核心集群回源等多种动态调度备线方案。 当其中一个节点出现网络抖动或故障时，其他节点可以即时从备选线路回源。 至此，各层级集群发展为“节点池”的概念，也就是不再依赖人工运维状态下的以地域划分集群，而是形成核心集群池、二级边缘池和一级边缘池，分发回源和推流回源通过流控中心实时探测生成最优线路及多条备线。 特别一提的是，普通CDN是通过IDC到IDC进行网络质量探测，而京东云基于京东商城配送站资源，将其模拟为一个端探测CDN边缘节点质量，提升边缘节点到用户的最后一公里质量。

直播分发 服务 性能调优

我们知道直播云质量评价核心指标包括首开时间、卡顿率、内容延迟和可用性，上面所讲架构演进更多是围绕可用性提升展开，京东云在首开时间和卡顿率方面也做了很多优化工作。 首开时间的消耗主要在DNS解析、TCP建连、应用层握手及协商、数据发送等几方面。 要加速首开，最简单可以想到的就是通过主动预热把流提前拉到边缘节点： 视频数据距离用户越近首开时间一定就快。 但对于直播长尾效应而言，预热这种手段对CDN来说无疑具有非常巨大的成本压力，常态服务时无法使用。 长尾效应下存在大量的直播冷起播放，针对冷起情况下的首开优化就尤为重要。 在内部交互（一级边缘到核心集群）中我们通过“去DNS依赖”和维护“长连接的TCP连接池”的方式消除DNS解析和TCP建连的时间消耗，而一级边缘到用户端可以通过在Client端进行“DNS预解析”节省DNS解析时间（这部分需要Client进行优化）。 于此同时，针对应用层握手及协商过程，京东云放弃了原生的RTMP协议（需要5-7个RTT），内部使用私有KTMP协议（playload兼容RTMP），在1个RTT完成握手及协商，这样极大的降低了握手及协商过程的交互开销。

其实针对首开时间的优化很多可以同时降低直播卡顿率，比如TCP连接池在网络发生抖动需要重新选路时可以更快速建立连接。 但当CDN网络抖动导致丢包严重时，TCP表现就会有很大问题。 京东云 自研了进行RTMP和QUIC协议转换的Converter，部署于上行边缘和下行边缘： 在上行边缘我们将RTMP转换为QUIC在内部传输，而当一级边缘分发给用户时再把QUIC转回为RTMP或FLV，这样，CDN节点之间网络丢包引起的卡顿将极大降低当然，网络更多的抖动、丢包是发生在最后一公里，这就需要Client协同做一些工作进行QUIC推流接入及播放接入，以期降低更多延迟。

大规模、高可用直播平台架构：提升性能+降低成本

直播平台是基于端到端的处理，京东云是如何基于前面提到的底层高性能视频编解码、大规模存储、性能保障和CDN链路优化之上构建更友好的直播服务？ 下面将通过直播产品化高可用方案和性能提升详细讲解。

直播产品高可用方案

在推流质量和稳定性保障方面，京东云在链路选择、推流加速、多源站部署、稳流/预处理和多种推流模式5个方向优化，首先在推流链路选择上提供应用更为广泛的边缘CDN节点和质量更高的源站直推两种，边缘收流后会通过CDN加速中转到源站，并且通过多源站部署保证源站稳定性，同时提升推流性能，而稳流和预处理则更好的保证了生产系统和输出流的稳定性，以及对不规范的流进行规范化处理和修复。

除了推流质量保障，如何通过技术手段保证系统生产过程的稳定性？ 从设计体系角度我们通过模块化、配置化和监控体系来完成直播流的稳定生产。 目前京东云采用微服务架构，每个模块独立部署，高内聚低耦合，当某些模块出现故障时，内部会采取服务降级或熔断机制，从而缩小故障带来的影响范围。 在服务模块层，通过标准化+配置化设计满足不同需求，比如转码码率、分辨率等； 在业务层也可以基于不同服务模块的能力进行封装达到不同应用、不同场景的定制化。 而一个稳定的系统离不开完备的监控体系，当出现问题时如何快速发现、快速定位、快速修复。 对于直播平台下的生产集群使用任务的方式管理，我们把某一任务的输入、处理过程和输出采用配置参数，通过调度系统将这个任务下发给一台机器进行生产，而生产的健康状况可以通过这台机器上报的数据进行实时监测、追踪和修复。

降低资源成本，提升平台性能

在底层技术优化基础上，从平台层角度，如何更充分利用资源，如何合理调度任务完成生产，让整个系统吞吐更大、速度更快、利用率更高，同样是“降低成本，提升性能”的重要一环。

下图是资源调度系统架构，它包括对服务器、节点、网络、调度等的管理，以及服务器和资源利用率的监控，它实时监测内部运行状态和使用情况，比如哪个节点出现问题、哪台服务器利用率比较低等等，当某一节点长时间利用率较高，我们就需要判断是否需要扩容或调度策略需要调整，从而达到利用率最大化和调度均衡的平衡关系。

在调度中，不同任务消耗的资源重心也会不同，比如转码对CPU消耗较多，而另一种业务对带宽消耗较多，因此我们抽象了一个load的概念，用它表示任务在机器上的综合指标，我们通过算法不断优化load值从而提升整体资源利用率。 而在调度过程中可能出现由于信息延迟导致一个任务分配到一台机器之后发现资源不够的情况，这里我们引入了超频的概念，如果当前任务所需资源超出部分在这台机器可承受范围内（我们设定一个百分比的过载保护机制），则不需要再进行二次调度。

尽管针对“京东云视频云端到端产品技术实践”的精彩技术分享已暂时告一段落，但关于音视频编解码、海量数据存储、高可用CDN网络架构等诸多问题依旧被火热探讨中，未来敬请关注京东云开发者社区（ID： JDC_Developers），了解最新技术活动。

依托京东集团的业务实践和技术沉淀，京东云视频云提供了端到端一体化服务，打通采、编、制、录、存、管、播等环节，让视频的生产和流转更容易，通过积木化的方式各项能力自由组合，满足客户对于视频业务的不同场景和需求。 点击“阅读原文”查看京东云视频云服务，马上开启试用之旅吧~