增长一直是业务的诉求，和增长相关的因素很多，内容、人群、创意玩法、性能体验等等，本次LiveVideoStackCon 2021 音视频技术大会 北京站 我们邀请到了火山引擎点播技术研发负责人——浩铭老师。本次分享聚焦在字节跳动视频通过性能体验优化促进业务增长的实践。包括在分析方法上的探讨，如何衡量和预估体验优化对业务增长的贡献，以及具体的体验优化实践分享。

文 | 浩铭

整理 | LiveVideoStack

首先呼应一些LVS包总在主论坛演讲的内容，本次分享也会围绕35岁和数据。首先是35岁，指我个人，在35岁时离开大厂，开始云服务创业，经历几年创业后再来到字节，感受到不同做技术构架构的方法论。有两个挑战：一是经历了2016年直播元年，看到新技术增长爆发，对于视频行业所有从业者机会；二是加入字节后感受到了数据的价值，和之前认知的做事方法论不同，一边做一边总结，就有了本次分享。在4年多以前来LVS分享过，那时候还在做云服务，基本上做了两三年，觉得入门了，主要做云服务治理稳定性和如何在厂商之间PK拿到更好分数。回过头来看，在C端从业一段时间后，对当时做法有一定认识，开始明白做云服务时始终不理解的为什么SDK一直卖不进大客户。

本次分享主要分为以下三个部分：首先是将我谈的话题以增长还是质量为目标做简单定义；然后介绍在面向视频体验优化能力在建设上的行动，由于公司都在用同样方法做事，前面同学讲得或多或少都有些体现，更多地谈一谈做的理由和背后的思考；最后由于我们对内是中台，对外也是希望云服务方式能够把能力输入出来，以推广为目的，把能力沉淀，更多的输出以及一些展望。

1、目标定义：增长or质量？

首先看一下增长和质量。

1.1 目标定义的矛盾

在做云服务的时候经常会听到核心指标，甲方和乙方都会关注这些指标，比如起搏耗时、卡顿、画质等。这个话题对不论是客户和或是云厂商都很苦恼。客户也希望保证服务是好的，需要有衡量方式，用云厂商的时候需要知道用什么指标促进其不断进步，会去想用什么方式去衡量。对于云厂商来说，看到这些指标就要去想优化的动作。之所以说是蛮痛苦的过程，我也经历过这些角色，在云厂商看到这些指标，一方面会去想如何将其优化，另一方面我也发现指标定的不完善，有很多可置换的地方，完全可以通过PK策略把指标换的很好，客户没有提到的指标变差，甲方也想将衡量指标变得很完整，确实有一些比较困难的点：如果更看重画质，提升画质，起播耗时、卡顿可能劣化；如果优化卡顿指标，画质可能劣化；如果缩短用户感知的起播耗时，达到秒开效果，卡顿可能劣化。

以哪个指标为主更好可以分几个阶段看，当有能力在指标之间不用做如何制衡就能独立优化时是最好的，用技术实力将每个做优化。但优化到一定程度进入深水区，不得不考虑制衡方式，将会是比较难的话题。大家很容易理解卡顿和首帧哪个做极致优化对用户更好，这样类型的问题放在面前不经会想评估标准不够高，有可能有更顶层的指标没有被考虑，用它衡量置换关系会更合理。

1.2 播放体验和灵魂拷问

接触到C端业务后，发现虽然业务方和云厂商说的是指标之类的要求，自己其实真正关注的是业务结果，例如：业务数据不好，是不是因为播放体验有问题？很难回答，假如看到抖音的DAU有微弱的下降，能不能说是播放质量的问题，还是刚刚提到的很多运营、人群的问题。刚刚说的存量业务随着时间指标劣化原因是否与我们有关。如果花了很大的力气，新上线的feature，对业务的贡献如何？产品和竞品之间播放体验的差距是什么？我们总说极致体验，到底什么是极致体验是什么，以及怎样才算极致？这是在做C端业务支持字节内部各个业务发展时会面临的问题。

1.3 QoS和QoE理念

这些问题的回答很有难度，可以看到共性，业务最关心的还是业务数据。业务数据包括DAU留存、广告收入、成本等。从业务收入往下看到与我们相关的QoE，指播放次数、播放时长、完播率、投稿量、投稿率这些指标。在最开始讨论画质时，AB在看画质时看什么指标，在考虑AB时不用考虑技术工作，是业务问题，不管做什么优化动作，看的都是相关QoE指标、播放次数、播放时长。例如做一些C端玩法时不一样，会看渗透率、评论率等，这与多媒体无关。多媒体强相关基本围绕上图列出的QoE来看。无论做的是卡顿优化、能力优化、画质优化，指标都不变。

我列出了一些常见的QoS，包括播放失败率、起播时间、卡顿指标、画质指标，在支撑QoE上来说即使再完善QoS也不全面，因为很多因素都对体验项有影响。如果人群因素（老年、年轻）、运营活动影响、以这些体验优化，更为可控的还是多媒体能力相关的。

本次希望聚焦在列出的和视频能力相关QoS指标展开讨论，看这些指标如何影响到QoE，以及如何去衡量和制造工作。

1.4 面向体验优化的一些不同做法

在开始提到了AB实验，提到的难点都是缺少更上层的指导原则，但看指标PK更像是过程指标。如果有更上层指标，过程指标的好坏有了判断条件。这里非常推荐AB实验，不是说QoS不好，但可以通过QoS指标自己给出公式衡量业务是否很好，厂商提供的服务是否很好，难度非常大，在理解力不够情况下，很难短期给出合理指标。但AB实验对希望提升标准给了方法，直接告诉结果，无论上了何种能力，直接从业务结果看能力结果的好坏，字节有了这个能力就可以用这个方法。有了这个方法后，最大的不同会暴露出元无知（原先我们不知道自己不知道）的场景。

举个例子最开始做AB实验的例子：当时想要在字节内部推自研的播放器及其自研的编解码器用来提升体验、降低成本。我在之前云服务时做过，在能力上没有新的东西，没想到推两个能力过AB达到正向结果花了将近8个月时间，做了上百次AB实验，再来一次我一定分别推这两个能力而不是同时。期间经历了很多元无知，中间AB实验告诉我在上这两个能力之后，用户评价意愿变低，怎么也想不通为什么一个播放器功能和编码更新升级会让用户不愿发评论，这是一个核心指标。它告诉了我这样的结果一定是哪里有问题但我不知道，之前提到的首帧卡顿失败率指标都没有变差，我也建立不起来为什么会影响到评论，只能看无知的地方。突破无知的场景有很多，可以看竞品或与人聊，不断增加埋点，陆陆续续建设庞大的埋点体系，包括音画不同步、Seek耗时、未起播、功耗、流量的浪费率、画质。

我们之前并没有评价画质的能力用分辨率或是码率代替都不是很合理。码率升高或降低并不能对画质做直接衡量，用线上用VQScore评价指标方便的去衡量可能出问题的地方。面向体验和质量的两种做法在我自己看来最大的挑战是面向自己的元无知，承认自己有东西不会，不断通过AB实验找到不会的点，将其露出来，也许在一段时间后对于稳定的业务给出一个QoS组合去衡量能力好坏的方法去代替AB，但很多产品现在还做不到，比如CDN产品很成熟，业务可以用速度和成功率等指标去衡量CDN厂商做得好不好，但新的传输方案PCDN因为涉及端上的能力，指标体系更复杂，在短时间内无法建立对其合理的QoS评价标准，在这个产品上我一直强烈反对用QoS打分衡量做得好不好，而是一直在用AB实验。这是不同的理念带来的做事方法不同。

2、视频体验优化能力建设

接下来我想谈一谈在这个理念下能做得视频体验优化到底有哪些。我现在主要做点播方向，举得也是点播的例子。大家都知道点播是一个很成熟的方向了。我在2012或是2013年时在百度做点播的服务，后来经历创业时候做直播，现在回来做点播发现其实差不多还是这些。

2.1 体验优化的技术空间来自哪里

上图是能力。现场有很多友商的同学，大家做出来都是这样，没有太大区别，在能力都基本同质，建构细节会有所不同，很多人会疑问以更高标准，以AB实验指导内部做事是否还有空间。

我与产品接触比较多，邀请中台产品做分享。他提到的一个概念：基本满足需求和充分满足需求，这是完全不同的两件事情，中台做到充分满足是大有可为的。如果想要基本满足，对于一个需求实现一种功能就可以完成；如果想要充分满足，就需要不停付诸努力，试错优化，找到最终最优解。他举了这样一个例子：人类在200万年前学会狩猎和采摘，之后基本满足食物需求，直到近现代才有农业机械改良后的高产作物和强大的运输能力，这时候才称得上完全满足。这个理念很有意思，代入到研发上也对应的上。接下来聊一聊这几年在字节做到充分满足我所做的事情。我做了一些印象深刻的归类但不全。首先是弱网弱机的优化，海外、全国、下沉业务都是字节所看重的，有很多不像一二线城市有好的机型覆盖和好的网络，像RTC业务也是在做白名单，对于弱网弱机有一定优化，在各类业务中都有所体现，基础设施带来的难度提供了在技术上更优保证体验不受损。

新技术比如H.265的播放，如果单单要达到H.265播放不是很难，很多云厂商包括我之前也有方案输出，为了方便的业务适配和快速接入软解。实验时发现在非常成熟大体量业务中，把软解换成硬解都会有1%以上的时长和播放次数提升，留存也是正向的。大家也许觉得1%数不太大，在成熟的大体量业务中，这个数字已经非常可观。H.265提升硬解覆盖率需要很多细节优化以及策略配合。控制策略方面实验较多，没有太多套路。有些能力用的好不好并不是中台的本事，而是业务方的问题，把很多能力暴露出去后，帮助业务方在不同场景下用不同参数开启不同能力。例如单列双列业务模式下是否要预加载，预加载的策略是什么，加载几个，空间的留出。我们所能做得是理解业务需求把更多能力放出来，另一方面可以参与到业务的一个个实验中，陪着业务将受益拿到并沉淀回来，这是我们能做的一部分空间。

前文都在说如何在现有基础上把更好的技术思路用起来，让体验有进一步的提升，成本优化是公司经营中重点关注的点，如果把成本控下去，可以让公司的财务现状更健康，很多成本优化是来自于对性能牺牲，我们的空间是如何在成本优化的同时不造成体验的劣化。上图中列了如果我们有50%的成本节省目标，不做成本置换情况下在能力上可以做的事情，比如编码器的优化、节省的浪费，以点播成熟业务来看，有很多浪费，达到60%，下载到客户端的数据根本没人看，这个成本是业务方自己在扛。但如果将这一部分的成本省下去，可能会带来AB实验的负向，在策略上深耕才能在节约成本同时，体验不下降。最后是单价优化的可能，选择质量不好但便宜的传输资源，会涉及到一些节点的调用和端上切换逻辑，AB实验蛮难通过，这些技术的难度带来了可做事情的空间。

这里指的是点播的，直播上会更多，有玩法带来的压力。

这是大概的统计数字，已经做得现状空间内差不多有39个已有策略，有的比较成熟像26个可以推广，还有一些在开发应用阶段。做一些归类，有编码、设备、功能、网络、渲染、缓存、档位、上传等。这里就不展开讲了。

2.2 零耗时首帧优化

举一个简单的例子代入刚才说的思路验证。首帧的例子大家理解，可以拿来演示一下。字节有对于零首帧分析优化的讲解，我拿着成熟的例子介绍。首先“零耗时”首帧并不是0毫秒，而是基本用户感知不到首帧存在，现在线上效果达到100ms以内。上图是一个很标准的图，很多第三方SDK和海外统计性数据平台有类似方式，它会记录起播时间，中间是否有未播放就退出，真正首帧结束时间，中间如果发生Seek或卡顿会将其时间点和耗时记录再到播放结束。最开始我们也是这样的埋点体系，这个体系对于使用就够了，如果想拿它去下钻深耕很无力，不知道其中哪里藏了可被优化的地方。

2.2.1 指标建设

所以第一件事情是重新建立指标体系。前文提到用8个月时间就是不断完善买点，看到底在改动时候，哪个指标变差，后面会有对其归类，在建设时不知道什么会出现问题，会有一些带有尝试成分，把所有能想到的都加上。其实在首帧产生时，在上下文环境之前，还有客户那里创建页面与我们交互。到我们有首帧准备，数据下载（其中到底选择CDN，P2P，解析结果是否要缓存，数据淘汰下来是否要做缓存，淘汰策略是什么）首帧渲染。

2.2.2 能力建设

这些埋点体系建立后尝试做归类，在每个类别里做什么样的事情。这里分了四类：一是与业务相关的，在这一页思路中在想有什么能力以不做置换情况下单纯靠能力提升做体验优化，而不是用牺牲指标来换。

首先是业务和业务交互，业务可以用多实例方式与播放环节交互。Video Decoder在硬解下stop release&start是有120ms耗时，如果把复用节省是一部分首帧节省，这里统计数据是优化首帧40ms以上，在预渲染方面会有单独的介绍。

网络耗时在SDN下载时有很多连接可以复用，不用释放，好处是将重新建联的耗时省掉。在做优化的上线之后，发起新请求，单独靠此能力，没有预加载的帮助开始接收数据不超过100ms。有了这个能力就有一些想象空间，用在点播只是基础，后续用多自由度或是VR需要切换视角时候，多路流需要有尽快完成切换的动作，这些场景都是可以用的。

我还列出了硬解初始化，和一些公司聊过，会觉得硬件是好，但首帧会变差。这里做业务初始化，业务是可控的，一些信息提前知道，不需要解析才能初始化硬解设备，可以提前做，达到硬解和软解差不多的首帧效果。以及一些fallback，如果一些机型不支持硬解，需要fallback软解，相比于单纯使用硬解，会增加20ms耗时。结合前文机型选择能力，提前知道哪些机型不合适走到硬解，这样就把fallback比例控制在0.3%以内。

最后一个大维度合的有点牵强，播放器策略逻辑耗时，这一部分不是必须存在的，是为了播放逻辑更好，人为引入，在首帧渲染之后不一定会马上起播，会缓存一段水位，到底需要缓存多少后续会有例子介绍，缓存多了会浪费，缓存少会卡顿。这种耗时是人为引进，可以被优化，有些场景是低清场景，例如西瓜视频竖屏观看有详情介绍，切换至横屏可能是720P或更高，竖屏为了保持切换流畅使用相同分辨率播放同一视频。如此小的窗口上这么高的分辨率没有感官上的差异，反而会有卡顿首帧影响，这一方面是可以被优化的。在把问题拆解的时候，做一些对应的优化动作靠着之前研发水平经验不是什么难题。主要想要分享我们是怎样进一步拆解，想到做这些事情的。

2.2.3 策略优化

上图是有些能力是我们自己能做的，有些能力是第一环节组合是业务浪费的，这是联合业务一起做的，这是业务的同学优化项目，我们来配合，类似抖音沉浸式的在划动时会切换下一个视频，最早做了预加载，暴露能力出去，业务做了很多尝试去知道预加载数量，每个加载时长最优。更进一步预加载后是否可以预解码，在有空闲的时候将解码动作做了，在用户划动时将解码好的那一帧投出渲染，这样首帧可以极大的被优化，最后想了一下预渲染的时机怎么触发。以前是将卡片划到下一个稳定了渲染，现在只要一松手就可以渲染，通过这种方式感觉不到首帧存在，这样的好处会先展示封面，之前加载图片也是需要带宽的，图片的性能优化也要做考虑，做预渲染方案图片都可以省掉。每次一划，下个视频第一帧已经被截好，图片意义不大。因为涉及到业务方使用姿势，无法在中台能力沉淀，额外出了将Demo最佳实践的方式开源，在官网和展台获取。

有了思路储备能力，面对首帧和卡顿如何权衡才是对业务最好的。实践的结果在内部各个业务中通过调优能取得完播率和播放指标的显著正向。但参数差异很大，没有统一结论。介绍一下过程。我们会有缓冲水位概念，有可播数据后不一定马上播，到缓存多大后才播是不停尝试的。最开始用静态拍缓存0秒或缓存1秒，分别看效果。后续明显看到1秒的卡顿明显好于0秒，实验结果来看，AB结果也是1秒好于0秒。不是所有用户都是弱网弱机，不确定这1秒有无浪费，设置成1秒有很多优化空间，逐步尝试不止看起播，把卡顿数据也列出，这是一体的，都是调整水位的动作，是动态水位优化策略。这里解释一下起播是缓存多少才起播，卡顿后的水位是缓存了多少后才出卡顿，这两个策略是连着做的。得出经验性结论在微调阶段，可以看出1秒留多了，降的时候可以看到显著的正向收益，但降到一定阈值后，要权衡首帧和卡顿。在AB实验看来用户会用卡顿更加明显，提升首帧后缓存水位从200ms提至400ms，用户体验结果会更好，卡顿减少。且不是每个用户都是静态，可以根据自身情况做调整。端上对之前发生和网络情况了解，可以在几个值中动态选择更好结果。对于能沉淀下来的能力经验包括水位值和业务相关。不同业务不同，稍长的业务用户对卡顿更能容忍，将一些优化能力在首帧。沉淀的经验对绝大多业务都有收益，业务类型很广。

3、能力沉淀&展望

最后说一下能力沉淀和展望。我们有很多积累性的方法，我代入了点播的例子，包括其他例子都是同样思路，但都会有一些门槛，包括储备能力、理解能力，建一个置信的AB平台都需要投入。字节每天都有超过1500次的新增A/B实验。在同一拨的用户分层干净，不互相干扰各自实验，影响双方至信度有平台建设性工作。如何将能力沉淀不一定需要通过完备方法，达到较好体验结果。

3.1 能力沉淀，快速横行复制

上图是客户端服务端数据结合的例子，大多数模块并不陌生。重点是客户端策略中心的部分，将之前沉淀经验都放在客户端策略中心模块，这是产品化的一部分，是随着点播SDK组件一起放出的，把之前积累的包括测速选档，预加载策略，弱网弱机策略经验放至策略中心。策略中心相对开放，业务有定制化二次开发。业务方比我们更了解业务，如果想要自己做更改，例如进入个人主页预加载策略就与单列双列不同，可在技术上做二次开发的更改，这是在产品化沉淀和之前做法思路不一样的地方，将深入业务零散的事情找了落脚点，客户端的策略中心能够被持续的迭代优化来源于自己的数据上报和统计，沉淀于策略中心，通过服务端下发，完成这样通路。不仅在内部，还具备对外输出能力，只是能输出客户端策略有限，在一点点打磨。

3.2 重视QoS指标劣化诊断

QoS指标很重要，但理解力不够，不以它为标准，但已经知道对QoE有强关联的QoS指标，它的劣化是不能被容忍的，在对QoS诊断上投了大量精力。包括QoS指标的监控大盘，对其自动归因，手动归因，单点归因，这些能力在其他云厂商也会有建设。不同的是我们希望把提效做到极致，发生指标劣化，第一时间没有经验同学也能知道发生事件的原因。我们除了完成四个能力建设以外，将连接这四个能力的线也做了产品化，让没有经验的人在看到大盘的时候也能得出结论，首先用智能归因明确问题方向，在下一步引入手动分析，对还有怀疑的地方手动看。避免自己经验和外部干扰，其中加入了弱引导，多个维度加百分比，百分比的含义是这个维度下有多大可能出现根因，让其尽量聚焦在引导的方向看，最后将大盘指标对应有特点的详细数据单独拉出，进入检测项目列表，对各种已知问题类型，比如有播放器创建检测、视频黑屏检测、劫持检测、播放URL过期检测，这些在日常会遇到的问题做针对性检测，找到对应问题和修复手段。

在不断演化过程中，智能归因可读性越来越好，从开始给出某个CDN异常上涨或某个版本劣化的结论，到现在可以给出类似有97%概率归因到恶意用户黑产导致的指标异常，理由是低端机型低版本集中，这是在提效方面做得事情。

3.3 使命&愿景

这是使命愿景的一部分，希望做得是数据顾问的角色，不止面向监控与排障，还想面向策略调优例如策略分析决定哪一套参数上线，没有被完全产品化，更多的是在case by case分析中，最后面向产品洞察，由于有很多类型业务，可以抽象成不同赛道，给行业做指导。产品同学问，我们与竞品相比的优劣，如果将抽象做得足够好，就可以给出在所在赛道好坏的建议。策略中心就是刚才提到的，和内部方法论结合较紧。把基础达到，功能指的不是基础功能如播放、下载，而是已有功能基础上做深耕不得不挖出的新功能，比如连接复用、水位阀控制下载节省流量，这些属于我说的功能，比较通用能看到业务收益，在策略层被使用在不同场景中，构建产品中心服务，这其中功能和策略属于自身产品化部分横向复制。场景层更多的是通过Demo开源，告诉理解到的最佳业务实践，如何写代码，帮助快速实现。现在开源的包括类似抖音快速刷新场景的实践，下一步会开源西瓜划动体验优化。

接这两个框图做一个总结，云厂商会有特别大的产品矩阵支持端到端的所有功能，希望和字节相关独特都在这张图中了，在支撑内部业务追求体验时，逐渐开出了数据顾问和策略中心两种产品，不同于云服务产品，但也会将其作为产品向大家开放，它不一定帮助云厂商增加营收、控制成本，但帮助客户做好体验、帮助客户把钱省下。在做字节内部业务的时候，对业务价值很大，但作为云服务并不多见，打磨好这个产品，是我们希望持续投入做的事情。

最后提下愿景，火山引擎视频服务希望能为更多业务方的使用体验、使用成本负责。

以上就是我本次分享的所有内容，谢谢。