作者|小阿里大文娱高级技术专家
本文是阿里巴巴文娱高级技术专家肖在【阿里巴巴文娱2019双11猫夜技术沙龙】上的演讲。主要内容是如何通过优酷智能文件，尤其是在双11的直播场景下，减少用户的停滞，提升用户的观看体验。包括具体智能文件的落地挑战、算法架构、技术策略。
一、优酷智能文件的前世
智能文件技术，即自适应比特率播放技术。一方面是比较新的探索尝试:因为优酷在这方面的投入在国内是走在前列的，是一家已经大规模产品化的流媒体服务公司；另一方面，这个技术本身也比较老了。大约从2000年开始，已经形成了比较完整的概念和框架体系，成为流媒体传输领域的标准产品技术形态。它在网飞和YouTube上被广泛使用。自适应码率回放技术不仅在国外业界已经有成熟的应用，在学术界也有成熟的研究。有些同学在本科和研究生阶段可能做过流媒体领域的相关技术研究工作。
但这么成熟的技术，优酷在整个大规模落地中，其实遇到了很多问题和挑战:
第一，国内用户不太明白这个功能是要解决什么，觉得这个功能“蠢”；
第二，用户体验本身是主观的，很难把握流畅度和高清之间的平衡点。
第三，开放算法框架的上线效果不是特别理想，主要是开放算法的特征纬度比较薄，对实际产品体验中的细节考虑较少。
二、智能文件带来了哪些改变？
优酷大规模上线已经有一段时间了，整体上线效果令人满意。
一是VoD整体卡顿缓冲次数下降11.1%，直播猫夜下降27.8%。
二是提高高清观看体验，保证服务的稳定性等。，并从工程实现方面做了大量的优化和考虑。在VoD上，高清播放时长占比提升约5.8%，这得益于算法根据缓冲时间和视频码率的动态变化，实现了播放远超当前带宽级别码率的视频片段，即在平均带宽仅为2Mbps的环境下，能为用户提供平均带宽为4Mbps的视频片段。
第三，随着时间的推移，用户越来越接受这种产品形态。真的很省心。打开视频看就行了。客厅到卧室，信号弱和信号强对整体体验的影响很低。
三、优酷智能文件的整体框架
整体技术架构主要由转码制作中心、内容分发网络和客户端组成。
在转码制作中心，我们把大文件切割成非常小的片段，大概5-10秒长。根据不同的定义，文件大小可能从500K到3-4M不等。之后这些小文件碎片被推送到OSS存储中心，再通过骨干网推送到我们边缘混合云的缓存节点。这些缓存节点包括传统的CDN和一些联合构建的边缘计算节点，提供相对廉价的内容分发服务。
从制作到分发，再到PC、电视、手机、平板等平台，本质上智能文件的核心框架是一个直白的逻辑:根据观看视频过程中的客观情况，动态选择1080P、720P、480P等不同码率的视频内容进行播放。
整个智能文件的产品化涵盖了几个产品技术问题:第一是如何从商业角度衡量新技术对用户体验的价值；其次，在技术层面，我们继续使用M3U8+TS的协议框架HLS，并尝试在算法中使用基于规则、混合、深度学习等不同的模型。最后，从工程和数据的角度，尝试对主观用户体验进行量化，建立QoE测量标准。
四、智能文件算法框架
智能文件的核心架构设计是一种强调C端和S端的架构。客户端基本上是播放器和智能文件决策模块之间的双向联动结构。所有的视频内容都被切割成一个10秒左右的切片，所以每个切片下载之前，播放器和决策模块有一个联动，决定这个切片是下一个480P还是1080P。这次下载后，播放器会通过下载器向决策模块反馈很多信息，比如TCP级别信息、网速信息、网络异常等。
同时，我们还有实时网络质量感知模块，会根据下载者的反馈和网络信号的变化，时刻感知用户客观网络环境的变化趋势，并进一步反馈给决策系统，以便更好的决策。
同时，每个算法的决策输入和输出会被汇总并发送回优酷服务器。结合玩卡顿的经验数据，基本可以形成标准的数据模型，用于离线算法训练。同时，C端和S端之间的实时数据链路也提供了相对较强的实时策略匹配和交付控制能力，动态交付差异化策略来控制决策系统的行为。后面我们再结合双11猫夜的工作来说说我们联动对带宽控制的效果。
5.智能文件算法综述
这个策略表是智能决策机制的直观抽象。该算法为每个可能的组合输入计算预期的QoE分数，然后选择最高的选项来执行。例如，策略表列出了五种可选定义，范围从4K到360p，有效带宽估计约为30Mbps。那么0.893是该带宽和当前网络质量的评估置信度。结合诸如缓冲器大小、二次阻塞概率等其他输入。，最终获得决策表，并通过选择具有最高QoE分数的一个来结束决策过程。在这个例子中，1080P的清晰度似乎可以接受，被卡的概率较低。选择这个可能是更好的策略。
整个决策环节有几个特点:一是动态决策过程，在播出过程中周期性进行；其次，要看你对带宽的判断和对网络质量的评价。在带宽判断方面，优酷做了很多工作，包括拟合方法和惩罚机制。本质上是期望提高预测带宽与真实带宽的相似度，降低判断错误发生时后续二次错误的概率。
六。低延迟直播场景面临的典型挑战
点播的逻辑和框架是一样的。但是直播最大的特点就是延迟低，所以可以提前缓冲的数据会少很多。尤其是像双11猫夜直播，其实是一个很强的互动属性。比如主持人在台上说“大家一打开手机就要去抢红包。”如果这个直播从主持人说这句话的时候延迟到你收到这个信息之后30秒，这个延迟基本上是无法忍受的。而基于HTTP的直播协议HLS，业内主流传输延迟为1-2分钟。其实能做到的速率控制和决策机制要好得多。优酷的后期直播有什么延迟？是三个4秒的切片延迟，即12秒的延迟。这带来的技术挑战是非常大的，因为在理想的百兆光网络中，播放器的数据缓冲最多可用8秒以上，也就是一次决策失误造成的时间损失对整体播放流畅度影响很大。
对直播网络质量的感知或者说对网速的判断和点播是不一样的。在按需场景下，网速因素的影响权重较低，缓冲时长的权重较高。当缓冲足够，网络质量好的时候，我们有充足的时间为用户提供更优质的内容。
七、带宽和网络质量评估
直播带宽的处理有几点不同:一是引入了谐波平均，大大降低了速度毛刺数据对整体评估值的干扰。如果只用算术平均，比如平均下载器过去2分钟的速度统计，偶尔抖动的影响会比较大。从统计学上来说，这种谐波平均会使噪声数据放大整体平均值，大大压缩。
这是我做的一个数据统计分析模拟。大部分速度分布在3000到4000Kbps的范围内。如果我用数据平均，得到的速度远远高于正常范围。如果用调和平均值，会更低。因此，如果将谐波平均与加权相结合，直播场景下的带宽判断会相对更加保守和稳健。
同时，在每一轮反馈后，结合惩罚机制，快速将速度判断的误差收敛到合适的区间。比如现在是第N个切片下载，累计的N-1个切片经过调和平均后作为当前带宽的估计。同时N-1片段的下载其实已经完成，所以既有Sn-1的真实速度，也有谐波预测速度。这两个因子一起将作为带宽预测的偏差惩罚因子，并且该因子将作为这一轮带宽预测的校正。
八。构建更加健壮灵活的直播能力。
直播场景下，智能档带来新的技术能力。基于这种动态的比特流交换能力和我们的实时策略联动机制，智能文件提供了非常完整和强大的流量管理和调度框架，比如基于位置、ISP、设备、场景等。，可以在整体带宽资源有限的情况下，做出更加精细化的流量运营控制。比如iPad Pro的2K屏要推1080P以上的清晰度，而对于手机有半屏观看交互的用户来说，把清晰度限制在720P就足够清晰了。
以上是2019年双11猫晚某一阶段对一批符合流量调整条件的用户的实时定义干预。基本上1分钟左右，蓝线瞬间下降，黄线瞬间上升，就很快完成了一次流量分配。同时，通过扩展HLS协议，可以在端侧支持两组主备流之间的自适应切换，从而支持容错等场景的稳定性要求。
九。建立测量标准
在视频播放的场景中，QoE是一个无法回避的坑。基本上所有通过数据和公式量化用户主观感受的尝试都没有特别满意。主要难点在于QoE期望找到一个标准来告诉用户哪个体验更好，是看480P从不卡顿还是每隔几分钟看1080P。这是一个很主观的话题，与用户习惯、设备特性、内容特性有很强的相关性。比如看到有精彩图片的东西，不希望图片粘贴下来，比如美食节目，自然风光；不过，如果你看一些访谈节目，新闻财经节目，贴上你的图可能也没什么坏处。重要的是要流畅。
因此，主观体验的客观定量测量基本上是困难的。下面是业内广泛使用的QoE评价标准公式。主要是在高清观看时长获得的基础体验评分基础上，通过惩罚切换清晰度、卡顿等负面体验，获得相对客观的QoE评价评分。整体评分优雅，但实际使用效果其实很差。第一个是这个线性加权因子的权重，实际上需要自己调整。比如，如果你不是很想让用户卡顿，可以通过增加卡顿惩罚的θ因子来粗略训练调整你的算法。
再来说一个直观的例子。例如，该算法在1080p和720p之间连续切换四次。根据公式的定义，1080p和720p之间切换的扣分比较少，从108p切换到480p的分数基本相同。但这种差异无法在公式中体现出来，而实际用户会立刻感知到这种差异，而且很明显高低码率的切换在视觉上会比较突兀，体验不好。所以总体来说，QoE公式只能在一定程度上得到解释，或者说逻辑上可行，但在实际应用中，指导实践的意义相对较弱。
X.选择一个好的测量标准。
在这个问题上，我们已经慢慢放弃用QoE来指导体验的优化方向，也不指望找到一个简洁优雅的公式。针对体验问题，核心思想是明确定义场景中的关键环节、环节和核心标准，并用这些子标准来定义好的体验应该是怎样的。比如起始场景，画面清晰度，延迟，要满足绝大多数用户的心理预期，保证80%的用户体验；比如在每一轮决议决策中，我们都很关心决策实施后多久。如果分辨率决定刚做到1080P，分辨率决定30秒还没发生，这也是很难接受的。
XI。寻求技术突破
在智能文件产品化的过程中，我们不断寻求一个问题的答案:对于这样一个成熟的技术，无论是在学术研究还是产业化方面，我们可以寻求哪些技术上的突破和发展？现在答案相对乐观。因为工业落地和学术研究的很大差距就是问题的复杂或者抽象，所以自适应比特率算法的学术研究已经被极大的抽象和简化，输入数据的纬度比较单薄。在落地过程中，迅速结合流媒体播放领域的工程经验和业务理解，丰富了决策算法可以参考的信息纬度，带来了决策的准确性、用户体验的突破和进步等显著效果。比如我们会结合用户的历史偏好、网络延迟、丢包率、TCP/UDP协议栈信息等。为了更好的评估带宽和网络质量的可靠性，同时加入更多的主观体验约束。比如坐地铁的时候，打开优酷看电影，手机4G信号可能在某一段时间内根本不行。传统的算法，当速度降到很低或者即将卡顿的时候，马上砍360P。这在逻辑上没问题，但体验并不友好。因为在这种情况下，降级定义毫无意义，肯定会卡死。为了保证更连贯的体验，也许我们只是在做决定的时候什么都不做，等网络信号变好，再提供更合适的观看体验。
技术创新的另一个突破在于云联动，即群体QoE优化。目前所有的端到端自适应算法都是围绕个体QoE最大化来实现的。其实从一个群体的角度来看，每个“自私”设备的整体体验未必是最好的，主要是带宽资源太稀缺。比如大家在同一个会场使用同一个Wi-Fi热点，通过云联动优化群体QoE。一方面提高了带宽的利用效率，同时保证了每个个体都能获得理想的清晰体验。所以群体QoE优化也是我们的突破方向。
目前国内带宽占用水平很吓人，因为有游戏直播，有主播直播，有Tik Tok和Aauto Quicker这样的短视频，有长视频的优酷。基本上大家都是晚上看视频。区域QoE协同优化帮助我们在极度拥挤的场景下让用户体验更好。
总的来说，我们的技术突破主要是突破自适应码率流相对纯粹的工程和算法边界，向更亲民、更智能的产品技术方向迈进。
十二。一些算法工程实践的经验分享
有将成熟的学术算法应用于工程业务场景的过程经验；
第一，要抓住算法框架的核心点，不要太在意结构性的东西。要看算法要解决的核心问题的突破点，看你想不想解决一个问题，有没有参考意义。第二，如果是大数据相关的算法，一定要注重数据集的质量和数量，结合自身业务，积累大量质量非常高的数据。这个底线不能变；
第三，算法效果的衡量标准一定要结合实际的业务场景，尤其是那些不是特别规范、难以量化的落地场景。避免僵硬地应用现有标准。毕竟你是最了解自己最想解决的问题的人。
第四，AB测试、大数据管道等工程系统能力确实大大提高了产品技术的迭代效率。比如智能文件开发过程中，我们以前每天都要在线运行十几组策略。一组控制策略平均运行2-3小时，得到较好的在线效果数据，大大提高了算法的迭代优化。
