立即领取|华润集团、宁德核电、东风岚图等 20+ 标杆企业数字化人才培养实践案例 了解详情
写点什么

如何利用播放器节省 20% 点播成本?

火山引擎-赵春波

  • 2023-09-20
    北京
  • 本文字数:5927 字

    阅读完需:约 19 分钟

如何利用播放器节省 20% 点播成本?

点播成本节省的点其实涉及诸多内容,例如 CDN、转码、存储等,而利用播放器降本却是很多客户比较陌生的部分。火山引擎基于内部支撑抖音集团相关业务的实践,播放器恰恰是成本优化中最重要和最为依赖的部分。


火山引擎的视频团队做了份数据统计,在一个很经典的视频业务中,我们在 2022 年至 2023 年大约 1 年半的时间里,针对这个业务进行了 33 次成本优化点,其中 13 次是播放器主导的优化,其余的有 12 次也是需要播放器强配合的优化也就是说在这个业务里,75% 的成本优化是直接或间接由播放器参与,可见客户端对成本优化的关键作用。


最终我们在很多实践中也发现,通过播放器的优化可以为点播业务节省 20% 甚至更多的成本,本篇内容便将聚焦在播放器层面如何节省成本这一主题上。

一、点播成本构成


在视频点播的成本构成中,有很明显的二八原则:

  • CDN 带宽成本占绝对的大头,80% 都是带宽成本;

  • 其次是存储和转码成本,二者占不到 20%;

  • 额外还有一些其他的周边的成本,比如日志处理的数据成本、AI 处理的成本。


我们可以将成本的优化理解成“置换”,在点播的成本优化中,就存在 2 种“置换关系”:


第 1 种置换关系是“成本项之间的置换”,指的是「带宽-转码-存储」之间的置换。



上图是 H.264 升级到 H.265 编码格式的例子,265 的压缩率相对比 264 要优 20%-40%,所以带宽、存储上 265 是大幅度减少;但是 265 的计算复杂度要复杂很多,所以转码成本大幅度升高。而这个图不是一个等边三角形,带宽成本要远大于转码和存储成本,所以这个置换是非常划算的


第 2 种置换是“成本和体验的置换”,我们一般说是“跷跷板效应:



例如:

  • 我们增大缓存时长,对应体验上「卡顿率」就会降低,但是成本会增加;

  • 抖音小视频 feed 流场景,我们做预加载,这时候首屏感会更顺滑,但对应的成本是增加的;

  • 降低码率,那么体验上感到清晰度变差了,而成本就是减少的;

  • 跷跷板中间支点是技术,我们通常是希望固定体验、降低成本,依靠技术来支撑。


所以我们总在说降成本,那降的到底是什么呢?我们这里用一个很简单的乘法公式来表示:


在过去,“单价”是非常明显的因素,大家往往选择在采购环节尽量的压低单价; 而“用量”上通常会被认为是无法改变的业务因素。但“用量”实际上是包含 2 类,一类是正常用量,确实是比较难改变的业务因素,但另一类是“浪费”,是可以被优化的。所以如何识别出浪费、降低浪费,是播放器降本的关键点


那么造成浪费的因素有哪些呢?



例如在视频播放过程中,会包括“已播放的数据”,和“未播放但已经缓存的数据”,如果用户中途离开播放,那其中“已缓存的数据”都是浪费了。所以我们定义“浪费”是“已经缓存了、但不需要的字节数”。


从理想上来说,没有浪费是最好的;但往往业务中,浪费是非常大的,大于 30%是很常见的。常见的可能带来的浪费包括了:

  • 未播放离开

  • 向后拖拽

  • 切换档位

  • 清晰度溢出(举例:很小的手机屏幕播放 4K 的内容,肉眼感知不到清晰度的区别)


二、播放器的成本优化方法


针对上述的浪费我们进行了如下的具体优化方法:

(一)缓存的浪费



承接上图的播放器缓存示意图,如果用户播放过程中离开了,那么深灰色是浪费部分。很容易就想到我们减少深灰色的部分的大小,比如把播放水位降低 1/3(也就是图中浅黄色的部分减少掉),不去缓存,那么浪费就明显的减少了。


这个就是静态水位的思路,通过减少缓存水位来减少浪费。


但是,静态水位是很难抉择的,水位大了浪费多,但是水位太小了,卡顿就会明显的增加。


这里有个马太效应,从原理上,缓存的本质是为了对抗网络的抖动的。网络稳定好时,只需要很少的缓存就足够了,但是网络好时缓存会填充的很快,大部分时间都是饱和的。反之,波动大的网络,需要更多的水位,但总的上限也有限,无法提供有效的缓存。


为此我们实现了的动态水位算法,我们根据一些因素来动态的决策缓存水位的大小

  1. 探测用户的网络速度和稳定性,对稳定性高、速度快的,我们减少缓存;对网络速度差、稳定性差的网络,就增大缓存,这样在网络抖动时就能够有更大的缓存空间使用;

  2. 根据用户的播放行为,通过数据分析道,视频观看的前期,用户离开的比例会更高,观看的后期,离开的比例就会降低,所以前期的缓存水位小一些,后期的缓存水位大一些;

  3. 一些其他的因素,但目的是在每次播放时决策出一个尽量合理的缓存水位,来平衡卡顿和浪费。


决定了缓存水位大小之后,还有个细节点就是 Range 请求。



Range 是 http 协议的一个请求头,默认是“0-请求”,表示请求完整文件。


左侧的图示意,如果是单独发一个“0-请求”,那么 CDN 服务端就会持续的返回整个文件,如果在中途断开,从服务端视角来说,这些数据已经发送过去了,无论客户端是否需要,都已经计费了,就构成了浪费。


在上图,我们分成 3 段来发 Range 请求,中途断开时,是可以停止掉最后一段,那么浪费就大幅度减少了。同样,静态的 Range 是很难抉择的,Range 拆分的太细会引起卡顿的提升;Range 过大了成本节省的效果又不够了。


这里我们引入目标水位的概念,就是刚刚讲的动态水位算法所决策出来的水位大小。


播放器 Range 请求的应遵循两个原则:

1. 将当前视频尽快缓存到目标水位。

2. 控制 Range 拆分的大小,避免太小的 Range 拆分。



上图是动态水位算法+动态 Range 拆分的效果示意图:


横轴代表时间线。纵轴上图是视频下载的大小,蓝色块代表一个 Range 请求;下图是缓存的大小,橙色的折线表示缓存随着视频文件下载和播放时间的波动情况,横着的虚线是目标水位。


我们从左到右,分析下目标水位和 Range 的关系:

  • 第 1 条竖红线,决策出来第一条目标水位 1,是启播水位,启播时的 Range 会略大于后面的 2 个 Range;

  • 第 2 条竖红线,是判断出一次水位提升,有可能是检测到网络波动,会提高目标水位到水位 2,同时做一次略大的 Range 请求来达到目标水位;

  • 第 3 条竖红线,是再次提升目标水位,到水位 3,有可能是因为观看时长增加到阈值,判断离开概率较小,所以保持高水位;

  • 后续的播放,在目标水位 3 随着时间波动,Range 大小也会稳定些。


从最终效果上看,在任意一个时间点离开,都能够保障相对合理的浪费。


我们在不同业务上实践了很多次动态水位+动态 range 的 AB 实验,在体验指标持平或更优的前提下,带宽降低 8%。

(二)预加载的浪费


在类似于抖音这种 feed 流下滑的场景,会提前加载好下面的视频,能够使滑动更顺畅,我们 叫“零首帧”效果,里面作用最大的就是预加载。


一般的预加载是固定几个视频,每个视频固定的大小。为了得到更好的预加载效果,会尽量多、尽量大的做预加载,也就构成了浪费。



我们做的“精准预加载策略”,在“时机、大小、个数”上做精细化的优化:

  • 时机上:对预加载也进行切片,这样可以区分出来一部分是紧急的,其他是不紧急的。比如图里,标记 P0 的是要最优先下载的,然后可以做预加载,预加载标记 P1 的部分,然后是当前视频的缓存水位,之后可以选择是否要预加载 P3 的部分。

  • 大小上:每个视频也会结合视频的长度、头大小、码率等因素计算出来需要预加载的大小

  • 个数上:按照 feed list 中的优先级依次预加载后续 N 个视频(动态计算),也会结合用户本身的行为(比如快速滑动)来动态决策。


AB 实验证明,能够提升预加载利用率 5%,对应流量成本降低约 0.8%。

(三)清晰度的浪费


现在的主干场景是在移动端看视频,大家都会有启播选档的策略,就是在播放启动时,决定所需要的清晰度,一般是跟随网速、码率来决策的。

经常大家面临的场景是,在竖屏里播放横屏视频时,实际上在很窄的一个空间里进行播放,这个时候,如果依然使用完整的清晰度,那么肉眼是看不出来的清晰的。而且,通常情况下小窗播放时用户的主要关注度也并不是画面清晰度,所以就产生了实际上的清晰度浪费。


我们对应的解决策略叫“窄屏低清”,就是识别出来显示区域很窄时,播放低清晰度的视频(比如 360P),当需要横屏时,再快速的切换为正常的清晰度。这里如果是 mp4 格式播放,需要转码也做些配合,支持 mp4 的帧对齐和平滑切换。


在很多应用中都是很常见的,也有常见的小窗播放,多个业务的 AB 实验都能有 3% 以上的成本收益;

另外清晰度上还有个很棒的能力,是客户端超分。随着客户端超分能力的优化,现在很大一部分机型在客户端向上超分一个档位是完全没问题的,耗电可以忽略。


对应节省成本的策略是“降档超分”,就是分发的清晰度向下降一档,然后再通过客户端超分降主观清晰度补回来。在国内当前的机型条件下,大部分业务能够有 6~8% 左右的成本收益

(四)异常流量的浪费


我们根据「播放器日志是否可以识别」、「是否是正常流量」把流量分成了 4 类。


在非常多的业务中会发现第三种情况:流量有异常浪费,比如有部分视频码率过高,可能是没转码,或者转码模版用错了。我们开始时会认为“这些都是很明显的失误,业务层小心点不就行了么?”,但后来我们做成了单独的异常流量分析模块。我们跟业务尝试分析原因,发现业务总是复杂的:

  • 业务场景很复杂,包括短视频、长视频、主页视频、广告视频等;

  • 研发的迭代通常会带来些历史问题;

  • 并不是所有的人员都需要持续的感知成本,只要有一个环节漏掉了,那么就可能会造成很大浪费。


这里还有个问题点,如果是体验问题或者 bug,总会有用户保障,来及时发现。但成本问题,用户基本是无法发现的,发现时就比较晚了。


我们是通过端到端的日志分析来发现和避免这些浪费的。原理很简单:

  • 在客户端对日志染色;

  • cdn 日志里记录的,区分是否是播放器产生的、是否是我们点播的域名;

  • 对两头的日志进行比对和分析。


不仅如此,这里还有个副产物,是通过这些日志分析,识别到业务真实是被盗链了,然后做盗链的治理。

三、数据挖掘成本优化空间


以上是火山引擎是实际业务服务过程中探索出的优化方案,但优化是不是有上限的,优化到什么水平可以达到成本和体验的平衡,更多的能力是通过数据能力持续的挖掘出来的。


先从结果上来看,我们成本优化后通常会有 2 个报告:

1、AB 实验报告,里面会分析对 QoE 的体验影响多少,对成本优化的影响多少,比如图中的人均播放时长增加多少,成本降低多少;做成本的 AB 实验,依赖一个工具——客户端成本指标。

2、价值回溯文档,用于核算真实收益有多少,一般发生在完整上量之后,比如 1 个月或 2 个月后。关键结果叫“万分钟播放成本”,这个对应的依赖的工具是“成本评估公式”。

(一)客户端成本指标



这张图从左往右是视频点播的数据流向。想要建设好成本埋点,有 2 个难点:


1、成本拟合。因为真实的计费数据是左侧 CDN 的计费日志,在右侧的客户端侧实际上是没有成本数据的,所以我们需要把数据缓存层的对成本的埋点尽量的拟合,使之尽量的对应到 CDN 的计费日志。这个过程是非常艰难的,我们通过了大量的离线校验。


2、提升可解释率。业务动作比较复杂(播放、预加载、拖拽、重播等等),举个例子,重复播放,播放层是记录 2 遍播放时长的,但是因为有缓存,真实的网络请求只有 1 遍。我们想要两份数据尽量对齐、可解释,就需要涵盖住尽量所有的业务场景。


我们当前达到了“可解释率达到 95%”,也就是说比如服务端 CDN 产生了 100Gbps 的带宽,客户端的日志能够拟合解释清楚 95%。


虽然还不到 100%,但日常来做成本优化、成本归因已经足够了。


下图是成本指标进入 AB 实验后的结果:


图:核心指标


图:归因指标


成本数据进入 AB 实验有什么用呢?有 2 点:


1、快速判断客户端的成本变化结果。大部分成本优化的能力都是伴随着策略的,不同策略有不同的结果置换关系,我们需要通过实验来确定效果。假设没有客户端的成本数据的话,我们就需要用不同的 CDN 域名来实验,这是很低效的,并且域名带宽的波动也会引起成本的波动。而在客户端成本指标进入了 AB 实验之后,大部分场景都直接看报表数字就可以了。


2、机制上可以防蜕化。业务的产品经理、分析师等角色也日常会关注到实验数据的,当成本数据也进入实验后,这些角色也可以关注到成本的变化,这样就能够防退化了。举个例子,版本升级时,只要经历了 AB 实验,就很难有成本退化的问题。

(二)成本评估公式


“成本评估公式” ,本质是一种单位成本的衡量方法。



我们叫“万分钟播放成本”,分子是点播的 IT 成本,分母是点播视频消费时长。


从技术侧来看,分子是“CDN、存储、转码等各种成本的加和”,分子是播放的时长。


这个公式很简单,但为什么要这么做呢?


因为涉及到成本优化,就会跟采购、财务团队打交道,采购、财务看到的都是每月的账单,业务用量每个月都在上下波动,导致账单每个月也都在波动。万分钟播放成本是单位成本,就可以刨除掉业务用量的影响因素,来衡量成本是否真的优化了。


拿其中的万分钟 CDN 成本来举例:


万分钟 CDN 成本的影响因子会涉及到价格、码率、浪费率、带宽流量比。


举一个真实的例子:有个客户反馈成本增加了,但是客户自己的业务用量在波动,不太好判断是什么情况。我们拆解分析万分钟 CDN 成本的具体影响因子,就发现了万分钟 CDN 成本确实是涨了 11%,主因是“码率”涨了 8%,“浪费率”增加了 5%。

四、总结和展望

(一)建标准


在服务业务的过程中,大家经常会面临一个问题,还能再降多少?极限是多少?


这些问题是很难回答的,因为每个业务的场景都不同,举例缓存浪费中,每个业务的客户中断离开的模型可能都不一样,那么建设统一的标准就很难了。


火山引擎目前通过 3 种方式来建设标准:

  1. 通过排名获取标杆:将类似场景的业务进行排名,对齐当前技术做的最好的,可以作为一种标准;

  2. 离线的实验来模拟:我们做了成本的自动化测试平台,设计测试 case,测试出来不同的参数的成本结果是多少,最后总结分析出来极限是多少;

  3. 通过“理论公式”来推算“标准” :举例通过“视频播放时长、中途离开比例”的关系,然后推算出理论的优化空间有多少。

(二)做顾问


面对的业务越来越多,降本的能力也越来越多时,就会遇到效率问题:功能这么多,应该用哪些?每个业务的场景也不一样,那么策略参数应该怎么配置呢?


万分钟播放成本分析和策略推荐


解决方法是做顾问。如上图所示,其是我们的一个万分钟 CDN 成本与理想万分钟成本的一个差异分析表,我们给计算出了对应的差异,然后再给出可以补足差异的策略或功能推荐。


当然,这个表只是一个总结概览,更多的内容我们会整理成“顾问服务报告”,把各个点的差异、业务分析、解决方法与业务逐一的讨论分析。总之,万分钟播放成本是一个非常简单、容易落地、价值很大的工具,大家计算下万分钟播放成本,如有调优的诉求,非常欢迎来与火山引擎交流。火山引擎视频点播https://www.volcengine.com/product/vod



本文作者简介

赵春波,火山引擎视频点播产品负责人。十余年视频相关研发和产品经验。目前主要负责火山引擎视频点播的产品工作,支撑抖音、西瓜等业务的点播基础技术、体验优化和成本优化等,并将这些技术能力沉淀到火山引擎,来服务更多的行业客户。

2023-09-20 09:004720
用户头像
鲁冬雪 GMI Cloud China Marketing Manager

发布了 362 篇内容, 共 255.7 次阅读, 收获喜欢 293 次。

关注

评论

发布
暂无评论
发现更多内容

心诺安 x TapData:快速搭建云中数仓,助力电商企业实施“以用户为中心的”精细化运营

tapdata

数据库

政界人士敦促拜登从尼日利亚带回币安高管

区块链开发团队DappNetWork

智能封面提取方案在广电媒体中的应用

爱AI的猫猫头

人工智能 音视频 低代码 办公效率 内容分析

京东商品评论数据接口(JD.item_review)丨京东平台实时API接口指南

tbapi

京东API接口 京东商品评论接口 京东商品评论采集

再见,PCA 主成分分析!

EquatorCoco

Python 人工智能 机器学习

堡垒机审计日志的定义以及作用概述

行云管家

数字化 堡垒机 IT信息

碳实践|如何快速掌握组织碳核算中范围3的计算方法

AMT企源

数字化转型 双碳 碳管理 碳核算

优化mac储存空间的方法 解决苹果电脑不流畅卡顿

禁止废话

Mac 软件 存储空间 CleanMyMac X 激活码生成器 苹果软件

8个实用的Java Streams API

快乐非自愿限量之名

Java API 开发语言

未来5年,只有这种产品团队才能开启上帝视角【玩转IPD】

IPD产品研发管理

产品 项目管理 产品开发 软件研发

抖音面试:说说延迟任务的调度算法?

王磊

复盘自研产品,总结技术实践

小院里的霍大侠

揭秘业务系统数据安全三大核心问题:“谁在用”、“用什么”和“怎么用”

极盾科技

数据安全

容器网络实现(中):为容器插上”网线“

EquatorCoco

php 容器 网络

Flink⼤状态作业调优实践指南:Flink SQL 作业篇

Apache Flink

大数据 flink flink sql

CoT思维链 , 大模型“智能涌现”的关键

澳鹏Appen

大模型 模型推理 AGI 智能涌现 思维链

新规:互联网政务应用安全管理规定将于7月1日正式执行

行云管家

互联网 政务

如何清理mac磁盘?快速清理小妙招在这里

禁止废话

软件 Mac 软件 电脑 CleanMyMac X

LPS完成战略性收购 增强数据实践和营销云能力

财见

数据库市场或迎变局 天翼云TeleDB打造企业数据管理最优解

Geek_2d6073

基于阿里云服务网格流量泳道的全链路流量管理(三):无侵入式的宽松模式泳道

阿里巴巴云原生

阿里云 云原生 服务网格

【AI应用开发全流程】使用AscendCL开发板完成模型推理

华为云开发者联盟

华为云 开发板 昇腾 华为云开发者联盟 企业号2024年6月PK榜

接口测试 Mock 工具使用 - 弱网测试

测吧(北京)科技有限公司

测试

开源鸿蒙的到来,鸿蒙生态该如何走向?

Geek_2305a8

如何利用播放器节省 20% 点播成本?_字节跳动_InfoQ精选文章