chanong 上图中，我们将范围请求分为三段。 如果中途断了，我们可以停止最后一段，浪费就会大大减少。
同样，静态范围的选择也很困难。 范围分割得太细会导致滞后； 如果范围太大，节约成本的效果不够。
这里引入目标水位的概念，就是刚才提到的动态水位算法确定的水位。
Range请求应该遵循两个原则： 1.尽快将当前视频缓存到目标水位。 2.控制Range split的大小，避免Range split太小。
上图是动态水位算法+动态范围分割的效果示意图：
•横轴代表时间线。 上图纵轴显示视频下载的大小，蓝色块代表范围请求； 下图为缓存的大小，橙色线表示缓存随视频文件的下载和播放时间的波动，水平虚线为目标水位。
我们从左到右分析一下目标水位与范围的关系：
• 查看第一条垂直红线，确定第一个目标水位为1，即起始水位。 播种开始时的范围将比接下来的两个范围稍大；
• 第二条垂直红线用于确定水位已上升。 可能是检测到网络波动，将目标水位提升至水位2，同时提出稍大的范围请求，以达到目标水位；
• 第三条竖红线是再次将目标水位提升到水位3，可能是因为观看时长已经增加到阈值，判断离开的概率很小，所以维持高水位;
•在后续回放中，目标水位3会随着时间的推移而波动，范围大小会更加稳定。
从最终效果来看，任何时间点离开都可以保证相对合理的浪费。
•我们在不同业务中实践了多次动态水位+动态范围的AB实验。 在体验指标相同或更好的前提下，带宽降低8%；
2、预加载的浪费
在像抖音这种推流下降的场景下，会提前加载后面的视频，这样可以让滑动更加流畅。 我们称之为“零首帧”效果，最有效的就是预加载。
一般的预加载是固定几个视频，每个视频都有固定的大小。 为了得到更好的预压效果，预压会尽可能多、尽可能大，这就构成了浪费。
我们的“精准预加载策略”在“时机、大小、数量”方面进行了精细化优化：
1）在时序上，预加载也进行了切片，可以区分哪些部分是紧急的，哪些部分是不紧急的。 比如图中标记为P0的就是最高优先级下载的，然后就可以预加载，预加载标记为P1的部分，然后是当前视频的缓存水位，然后可以选择是否预加载零件 P3。
2）大小方面，每个视频也会根据视频长度、头部大小、码率等因素，计算出需要预加载的大小。
3）在数量上：根据feed列表中的优先级依次预加载接下来的N个视频（动态计算），同时也会根据用户自身的行为（如快速刷卡）做出动态决策。
•我们对不同业务进行了AB实验，验证了该策略可以有效提高预载利用率，降低相应的流量成本；
3. 浪费清晰度
现在主要场景是在移动设备上观看视频。 每个人都会有一个启动和选择文件的策略，就是确定启动播放时需要的分辨率。 一般来说，根据网络速度和比特率来决定。
大家面临的一个常见场景是，在竖屏播放横屏视频时，其实是在一个非常狭窄的空间内播放的。 这时候如果还是用完整的清晰度的话，肉眼就看不清楚了。 而且，通常用户在小窗口播放时主要关心的不是画面清晰度，因此实际上存在清晰度的浪费。
我们对应的解决策略叫“窄屏低清”，就是识别显示区域很窄，播放低清视频（如360P），需要横屏时，快速切换到正常清清。 如果这里播放的是mp4格式，需要转码，做一些协调，以支持帧对齐和mp4的平滑切换。
在很多应用中都很常见，也有常见的小窗口播放。 多个业务的AB实验可带来3%以上的成本效益；
另外在清晰度方面有很大的能力，在客户端来说是超高的。 随着客户端超分辨能力的优化，现在大量模型在客户端超分辨一档已经完全没问题了，功耗可以忽略不计。
相应的节约成本策略是“降档超分”，即把分布清晰度降低一级，然后通过客户端超分降低主观清晰度来弥补。 在目前国内模式条件下，大部分企业可以实现6%~8%左右的成本效益。
4、异常流量的浪费
我们根据“是否可以识别玩家日志”和“是否是正常流量”将流量分为四类。
第三种情况在很多商家都会出现：存在流量非正常浪费。 例如，有些视频码率太高，可能无法转码，或者转码模板使用错误。 一开始我们想，“这些都是明显的错误，业务层就不能小心一点吗？”，但后来我们开发了单独的异常流量分析模块。 我们试图跟业务分析原因，发现业务总是很复杂：
这里还有另一个问题。 如果是体验问题或者bug，总会有用户保护及时发现。 但用户基本上无法发现成本问题，而且发现的时候也比较晚。
我们通过端到端的日志分析来发现并避免这些浪费。 原理很简单：
1）在客户端对日志进行染色，
2）记录在CDN日志中，区分是否是播放器生成的，是否是我们的点播域名。
3）对比分析两端日志；
不仅如此，这里还有一个副产品。 通过这些日志分析，识别出业务确实被盗，然后对被盗的链接进行管理。
数据挖掘成本优化空间
以上是火山引擎在实际业务服务过程中探索出来的优化方案。 但优化有上限吗？ 成本和体验之间能达到什么程度的平衡？ 通过数据能力可以不断挖掘更多的能力。
我们先看一下结果。 成本优化后我们通常有两个报告：
1）AB实验报告：会分析对QoE体验和成本优化的影响，比如人均播放时长增加了多少，成本降低了多少。 做成本AB实验，要依靠一个工具“客户成本指标”。
2）价值回溯文件：用于计算真实收益，通常是在成交量完全增加之后，比如1个月或者2个月之后。 关键结果称为“每万分钟播放成本”，相应的依赖工具是“成本评估公式”。
客户成本指标
这张图从左到右展示了视频点播的数据流向。 建立良好的成本埋点有两个难点：
1.成本拟合。 因为真正的计费数据是左边CDN的计费日志，右边的客户端实际上没有费用数据，所以我们需要尽可能贴合数据缓存层的费用埋点，使得它尽可能与CDN的计费日志对应。 这个过程非常艰难，我们通过了很多线下验证。
2.提高可解释率。 业务操作相对复杂（播放、预加载、拖放、重播等）。 例如，对于重复播放，播放层记录了两次播放时间，但由于缓存的原因，实际的网络请求只有一次。 如果我们希望两个数据尽可能一致和可解释，我们需要覆盖尽可能多的业务场景。
我们目前已经做到了“95%的可解释率”，这意味着比如服务器端CDN产生的带宽可以被客户端的日志清楚地解释95%。
虽然还不到100%，但对于日常的成本优化和成本归因来说已经足够了。
下图是成本指标进入AB实验后的结果。
核心指标
归因指标
成本数据进入AB实验有什么用？
1.快速确定客户的成本变更结果。 大多数成本优化能力都伴随着策略。 不同的策略有不同的结果替换关系。 我们需要通过实验来确定效果。 假设没有客户端成本数据，我们需要使用不同的CDN域名进行实验，效率非常低，而且域名带宽的波动也会引起成本波动。 客户成本指标进入AB实验后，大部分场景直接看报表数即可；
2.机制可防止变性。 业务产品经理、分析师等角色也会每天关注实验数据。 当成本数据也进入实验时，这些角色也可以关注成本变化，从而防止退化。 例如：升级版本时，只要经过AB实验，就很难出现成本降级的问题。
成本评估公式
“成本评价公式”本质上是一种单位成本计量方法。
我们称之为“10,000 分钟的播放成本”。 分子是点播视频的IT成本，分母是点播视频消费时长。
从技术角度来看，分子是“CDN、存储、转码等各种成本的总和”。 分子是播放时间。
公式很简单，但是为什么要这么做呢？
在成本优化方面，您必须与采购和财务团队打交道。 采购和财务看到的是每月的账单。 业务使用量每月都会波动，导致账单也每月波动。 一万分钟播放的成本就是单位成本，可以剔除业务使用的影响因素来衡量成本是否真正优化。
我们来分解一下10000分钟的CDN成本：
CDN万分钟成本的影响因素包括价格、码率、浪费率、带宽流量比等。
举个真实的例子：
有客户反映成本增加了，但客户自身业务使用量波动较大，很难判断到底是什么情况。 我们对CDN 10000分钟费用的具体影响因素进行了剖析和分析，发现CDN 10000分钟的费用确实增加了11%。 主要原因是“码率”增加了8%，“废品率”增加了5%。
建筑标准总结与展望
在服务业务过程中，大家经常面临一个问题：还能减少多少？ 有什么限制？
这些问题很难回答，因为每个业务的场景都不同。 例如，在缓存浪费中，每个业务的客户中断和离开的模型可能不同，因此很难建立统一的标准；
目前通过 3 种方式构建标准：
1）通过排名获得标杆：对类似场景的业务进行排名，并与当前技术最好的进行比对，可以作为标准；
2）离线实验模拟：我们制作了成本自动化测试平台，设计了测试用例，测试了不同参数的成本结果，最后总结分析了极限是什么；
3）通过“理论公式”计算“标准”：例如通过“视频播放时长与中途离开比例”的关系，进而计算出理论优化空间有多大；
成为一名顾问
当我们面对的业务越来越多，降低成本的能力越来越强时，就会遇到效率问题：功能那么多，该用哪些？ 每个业务场景不同，那么策略参数应该如何配置呢？
万分钟播放成本分析及策略建议
解决办法就是做顾问：上图是我们10000分钟的CDN成本和理想的10000分钟成本的差异分析表。 我们计算出相应的差异，然后推荐可以弥补差异的策略或功能。
当然，这个表只是一个概括性的概述。 我们会将更多的内容整理成一份“咨询服务报告”，对每一点的差异、业务分析、解决方案和业务进行一一讨论和分析。
10000分钟的播放成本是一个非常简单、易于实现且有价值的工具。 请计算一下10000分钟的播放成本。 如果您有任何优化需求，非常欢迎您与火山引擎沟通。 火山引擎视频点播。
微信扫一扫打赏
支付宝扫一扫打赏
