【51CTO.com原创稿件】
作者丨徐慧书
策划丨徐承杰
近几年直播和短视频的兴起，将整个音视频消费推上了一个新的高度，甚至可以说每一位互联网用户都是视频消费用户，并且其中相当多的一部分还是视频生产用户。作为一名技术人员，该如何去看待当下火热繁荣的视频消费生态呢?前不久，来自阿里巴巴的高级技术专家、UC 播放技术负责人徐慧书针对视频、播放器及视频启播技术优化等话题进行了详细地解读与分享。
视频的压缩存储
1、容器概念
如今，人们每天都会接触视频，视频文件很大，视频文件所包含的信息也很多。想要对这些信息进行组织，就需要利用容器。容器可以通过严格的规范，组织存放视频中的各类信息，在这个领域做的比较好的是 mp4。当然也有应对于直播、高清等各种差异化需求的一些其他的容器格式。而容器中所存放的最为重要的便是视频数据本身。视频的原始数据是非常大的，以 1080P 的电影为例，90 分钟时长，一秒 30 帧的帧率，其原始视频的大小大概是一万亿个字节，换算成更有体感的数据，就是 1TB。
2、视频压缩的多种方法
因此，在进行视频数据存储时需要对视频的原始数据进行压缩。视频是由一帧一帧的图片组成的，利用人的视觉暂留的特点，通过连续播放形成动画效果。因此在进行视频压缩时，首先需要考虑对单张图片进行帧内压缩，其本质是去除空间内的冗余信息。例如在这张图片中，女神的头发都是黑色的，如此以来，在进行图片存储时，一个宏块之中只需要存储一个像素点即可，这样做便可以实现空间冗余信息的大幅压缩。除了帧内压缩，视频压缩还有另一个重要概念——帧间压缩。视频在时间上有一定的连续性，因此视频中连续出现的图片会有非常大的相似性。在面对相似图片时，只存储差异信息，相同信息则不进行记录，这样可以使视频的压缩率保持在一个极高的水平。
除了对“量”的要求，视频压缩对“质”的要求同样重要。视频压缩是有损压缩，在压缩过程中，需要考虑人的视觉特性，对图像中视觉不敏感的地方进行大幅压缩，视觉敏感的地方则进行小幅度压缩，尽可能保证视频质量少受损失。在视频中每帧图像都是由像素点组成的，而每个像素点都是由亮度和色度这两个维度所组成。人在观看视频的过程中，对亮度的敏感性是更高的。但图像一般是由 RGB 三基色所描绘的，其中并没有亮度这个维度。想要保证视频在压缩过程中亮度不丢失，则需要引入 YUV 的概念。YUV 是图像的一种新的表现形式，Y 表示亮度上的分量，UV 表示色度上的分量。在图像的压缩过程中，利用 YUV 将图像的亮度和色度进行分离，便可保证压缩色度时亮度数据不受到影响。YUV 的转换公式较为特殊，该公式并非推导公式，而是来于自实验室的实验数据。是通过实验进行反复大量的验证，最终得出的实验参数。
Apollo & 秒播优化
1、初识 Apollo 播放器
Apollo 是 UC 一款内核自研的视频播放器，拥有高性能、高可用、高业务服务能力以及低资源消耗等优点。作为一款自研播放器，Apollo 在视频播放的流程上与其他播放器保持了基本的一致，首先进行数据获取，而后通过 FFmpeg 解协议解封装以得到原始数据，接着通过解码解压以及 YUV 转化得到 RGB 数据，最后通过 PDS 进行音视频同步并渲染到相应的驱动设备上，以实现视频和音频的呈现。而 Apollo 最大的特点，是接管了 FFmpeg 底层的数据网络库，并对数据层进行非常多的优化。
2、精准预加载的新思路
在如今的移动视频消费中，用户最关注的一点是视频秒播，而视频秒播则需要视频预加载技术的支持。传统的预加载方案面临流量消耗和秒播平衡的挑战，预加载过多会造成资源浪费，预加载过少则可能会由于数据缺失导致秒播失败。传统的预加载方案以视频文件大小为视角进行数据的预加载，但由于每一个视频秒播所需的数据都不同，因此传统的预加载方案例如估算和特定 size 的方法其实都无法做到对数据的精准预加载。而 Apollo 在执行预加载的过程中，以用户播放为视角并模拟用户播放的行为。当所加载数据达到启播需求时，将这些数据进行缓存。这样，当预加载命中时，就必然能够实现视频的秒播。但这也引出一个新的问题，播放是一个非常消耗资源的行为，不可能因为预加载的优化措施而浪费用户资源。因此，我们通过对整个流程的梳理与重构，将 FFmpeg 抽离为 FFmpegMediaStream，将其从捆绑式的播放流程中解耦，作为一个通用的基础组件供播放与预加载共同使用。这样即可在不启动高资源消耗模块的情况下，实现轻量级的模拟用户播放。
优化案例分享
1、Mp3 播放优化方案
一个传统的 Mp3 文件由头文件、音频数据及末尾的版权信息记录组成。在播放过程中，会优先读取头文件，接着跳转到末尾读取版权信息，最后跳转回中间读取音频信息并进行播放。这种读取方式在离线消费时代是没有问题的，但在在线播放时代，这样的读取方式会建立三次 HTTP 连接，每一次连接都会进行 TCP 的三次握手。在国内网络比较好的情况下，一次也需要 100 多毫秒，而在公域或网络条件较差的情况下，所需的时间更会成倍增长。为解决这个问题，我们取消了播放过程中版权信息的读取。由于在在线消费时代，这些数据都来自于 API 获取，且经过大量的数据分析，我们发现 Mp3 文件中末尾的版权信息都是无效数据，仅是用于格式对齐。因此这样做并不会影响 Mp3 文件的正常读取，且利用这种新的读取模式能够将启播的耗时降低 60%。
2、Mp4 播放优化方案
Mp4 的结构是由 MOOV 数据头和媒体数据组成的，在 MOOV 数据头中会详细记录视频中的每一帧信息，因此视频时间越长，MOOV 头数据就会越多，这也就是在观看长电影时启播速度慢的原因。当然这依然是较为理想的情况，在现实情况中，FFmpeg 在处理视频时，会默认将 MOOV 头后置，这会导致启播从一次 HTTP 连接增加为三次，进一步增加启播的耗时。在进行这类场景的优化时，针对这种内部自 seek 情况，可以将前一次的连接任务进行保存，当完成 MOOV 头数据读取后，再进行连接复用，这样既可以减少一次 HTTP 连接，还可以增加网络吞吐量。这种 MOOV 后置的优化方式，可以将 Mp4 文件的播放性能提升 10% 以上。
3、HLS 播放优化方案
HLS 是苹果推出的一款流媒体传输协议。由一个后缀名为“.m3u8”的 TXT 的索引文件与指定个数的 TS 切片文件组成的。m3u8 文件记录了每一个 TS 文件的时长、顺序与下载链接。HLS 视频的基础播放流程是，首先开始 m3u8 文件的下载，而后对文件进行同步的解析与下载，接着逐个下载 TS 文件直到用户播放。但在长电影的播放场景下，TS 文件的个数有可能会多达几千个，这将影响视频的启播速度。针对这类场景的优化，我们采用的是在解析 m3u8 文件时，增加流失解析，解析到第一个 TS 文件时即开启预下载，等解析完 m3u8 文件后再去做第一个 TS 文件的下载，这样就能够将 TS 文件从网络数据的下载，转化为本地数据的获取。如此以来，TS 文件的下载效率将得到极大的提升。
总结与展望
本次分享主要介绍了视频与移动播放器的概念，以及视频秒播优化的一些思路和方案。在未来，更加丰富的业务场景还将对播放器的极致优化提出更多新的挑战。视频起播全链路耗时治理，公、私域视频特点结合的优化提速将会是 Apollo 技术团队后续的重点研究方向。希望在将来能够给大家带来更加丰富的成果展示与技术分享。
嘉宾介绍
徐慧书，阿里巴巴高级技术专家 /UC 播放技术负责人，负责阿里创新事业群播放器技术团队，致力于打造业界最快的视频播放器。服务 UC 国内、国际浏览器数亿音视频用户，不断提升用户公、私域音视频播放体验，同时拓展阿里集团支付宝、钉钉、高德、天猫精灵、互娱等多个超级 App 及数十个业务板块的 web& 小程序视频播放业务，承载每日近 30 亿的视频播放量。
2022 年 4 月 9 日的 WOT 全球技术创新大会“音视频体验优化”专题中，徐慧书老师也将作为演讲嘉宾为大家带来《Android 自研播放器起播性能优化》的演讲。主要分享除常规视频秒播技术优化外，基于自研播放器的视频播放全链路研究成果，内容涉及视频的数据加载、预加载、硬解码、主流格式针对性优化等方面的进一步优化。除此之外，来自阿里、快手、Disney 等企业的数位资深技术专家，也将在该专题中为大家带来有关音视频应用体验优化的最佳实践经验分享。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
