对于一个视频相关业务（在线直播或者点播）的客户而言，CDN 和 转码是两个消耗最大的技术成本，至今很多在线流媒体厂商还在持续亏损中，无论是转码还是 CDN 本质上还是一个权衡，技术投入和用户视听体验之间取得一个的平衡；早在年初《聊直播，这些知识点你必须要懂》这篇文章中，我们就引用了亚马逊 Twitch 平台首席研发工程师沈悦时老师的一个直播三角来界定用户体验和 OTT 厂商投入之间的关系：
- 可扩展性：同时承载的在线观众数量，而且可以随着用户数弹性扩索容
- 低延迟：比如视频发布到接收端看到，又比如对话实时互动，又比如弹幕互动等等都需要低延迟
- 高服务质量（QoE）：画面质量，这个在某些场景非常重要
AWS 平台上拥有类似奈飞（Netflix）为代表的在线流媒体客户，在 2017年的 reinvent大会上，奈飞团队就透露，当时的转码消耗的 CPU 占奈飞全部 CPU 资源高达 70%，30万核的规模，奈飞团队在高可扩展，弹性以及低成本的转码任务方面做了相当多的努力，结果也非常显著，奈飞团队当时就取得了 92%的成本节约；奈飞是典型的大规模文件转码任务的代表；
而亚马逊 Twitch 是全球除中国市场之外最大的在线互动直播平台，同样在 2017年的一次公开分享《超高密度游戏直播转码架构》中，沈悦时老师提到，当时 Twitch 最高可支撑200万+并发观众，4万+的并发直播频道，由于是在线直播，跟文件转码的离线任务不同，Twicth 做了非常多的努力，软件优化+硬件转码方案的部署使 Twitch 的转码容量在 2017 年提高了 10 倍，3年的 TCO 是现有软件解决方案的 1/5 成本，同时正式支持1080p60 6mbps高清，超过 50% 的 Twitch 用户观看 1080p 高清直播。
可扩展性
类似奈飞的视频点播，可以提前进行视频文件转码，在客户点击播放时，直接选择相应码率和编码格式的视频进行加载播放，在日益丰富的不断增长的新的视频（UGC、自制剧、第三方版权视频等等），基于文件转码任务的弹性扩展是每个客户都需要的；类似下图奈飞团队的做法，核心几点：
- 优化闲置资源（低成本的闲置资源）：比如 AWS 的 Spot实例，用户自身业务波峰波谷释放出来的预留实例等等
- 弹性伸缩：转码任务微服务化，利用消息队列进行优先级管理，同时根据队列深度进行任务编排
- 提升单个转码任务效率：单机多转码任务并行，深度挖掘物理硬件性能 Intel CPU，Nvidia GPU 还是 AWS 的 Graviton （ARM CPU）
对于类似 Twitch 的实时在线转码，稳定性和高可用，是在考虑可扩展性的两个前提：
- 支持主备两路实时视频流：保障实时直播的可用性，当主线路故障时，自动切换到备线直播流的能力
- 高效的实时转码和转封装：对于互动直播而言，主播推流到平台，平台需要实现实时的转码或转封装能力，这也是 Twitch 团队核心优化的技术点
- 弹性伸缩：互动直播业务可以看成是一个有状态的长链接服务，很多平台并没有实现实时转码的弹性扩展，但用户侧而言，直播业务的波峰波谷特征非常明显，有状态服务的弹性伸缩，关键是要实现一个实时流的源服务器调度中心，当该源服务器上的推/拉流用户比较少的时候，在不影响用户体验的前提下进行合并转移，类似游戏服的并服操作；这块具体可以参考 Amazon GameLift 的实现或网易游戏的游戏服在 AWS 上的自定义弹性扩展器的实现；
容器转码？
我们接触的很多客户的转码团队，都期望或者已经实现一个基于容器的转码平台，好处是，转码细节打包进容器，团队更多关注，转码的输入输出以及定义一个转码任务技术参数的 Profile，AWS 的托管转码服务 Elemental MediaConvert 就是类似的一个广播级，底层基于容器的弹性转码服务，我们直接借鉴该服务如何把转码参数规范化成一个工程复用的 Profile 模版文件；
基于文件的转码容器镜像，常规的基于 Intel CPU 的转码任务大家比较熟悉，但有 GPU 转码或者想尝试基于更高性价比的 AWS Graviton ARM CPU 的转码容器打包，很多客户会遇到不少问题，AWS 媒体架构师团队，从大量实践中，总结汇总了不少可以直接借鉴的经验和实践，大家可以关注文末 9月份上海的市场活动。
无论是选择自建还是利用成熟的托管云服务实现大规模转码任务，用户都有选择的权利，引用一张同事的图表展现了云上不同文件转码实现方案的优势和逆势：
转码成本
悦时老师分享中一句话我印象特别深刻，就是 Twitch 早期也是类似国内大玩家一样，端到端都是利用 RTMP 进行推流（主播 RTMP 推流，平台再 RTMP 推流给终端用户），RTMP 好处是容易实现用户侧低延迟但成本高，Twitch 2011年成立，2013年开始流行，用户增多，公司基于 RTMP 的推流成本节节攀升，亏钱严重，从而有过一次大面积裁员；而在这个时候， Twitch 技术团队从 RTMP 推流转型成 HLS 拉流，扭亏为盈，据 Twitch 团队估算，同样一台服务器，同等 CPU 算力和内存的情况下，用 RTMP 推流和 HLS 拉流对比，能承受的观众数量密度是 1：5 的关系，用 HLS 还有一个好处是可以利用 ABR（码率自适应播放） 和 QVBR （定义质量的自适应码率）技术，同时 CDN 可以进行内容缓存，降低回源成本。
AWS 托管的 Elemental 视频转码服务支持 QVBR （定义质量的自适应码率），相对于传统的固定比特率 (CBR) 和自适应比特率 (VBR) 而言，可根据内容做出调整的 VBR 控制模式，在保证一致视频质量的前提下，尽可能减少浪费的比特资源并调整视频码率；从成本角度而言，QVBR 可以节省最多 50% 的 CDN 分发和存储成本，同时不需要更换客户播放器；
静态转码集群还是弹性动态？
我们见到很多客户，可以实现转码服务本身的弹性，但往往忽略底层转码资源的弹性；而端到端的弹性伸缩，往往可以帮助客户节约大量的成本（30%～50%）；而奈飞团队更夸张，内部实现了一套类似 AWS Spot 市场的策略，当监控到有空闲的低价（预留实例，Spot 实例等）就加入到转码集群，并通过消息队列进行任务的计划、编排和解耦， 结果节约了 92%的成本；
奈飞团队的自定义弹性扩缩组件，实现横跨 AWS 三个区域的资源调度，包括一个部署调度组件，监控资源可用和队列任务长度，所有的信息都会汇总到一个计划组件，任何一次扩展或收缩都不是立刻执行的，其中任务编排组件负责具体调度转码任务的执行，具体操作交给扩展和收缩组件；其中，如何选择恰当的 EC2 计算资源，复杂和难点在于，很难精确计算需要多少转码资源，并充分利用 CPU 资源，奈飞团队的做法是，泛化成容器 CPU 资源粒度，进行粗粒度估算，不同的实例 EC2 类型大小，调度执行不同数量的转码任务；
线下转码技术活动报名
随着短视频，直播的快速发展，很多行业客户比如电商直播，媒体，视频工具，在线教育，云游戏等等都会涉及到转码任务的处理，转码任务是一个计算密集型工作负载，有离线批处理模式和在线处理模式两种，底层的计算资源有基于 CPU 转码也有 GPU 转码，甚至利用性价比更高的 ARM CPU 进行转码任务；而云原生的转码实现可以帮助客户在满足性价比的前提下，保障最终用户的体验。
本次研讨会，是大规模弹性转码主题的基础篇，侧重在 AWS 平台上客户如何实现一个云原生的容器转码方案，包括利用云原生对象存储来管理视频等多媒体内容，利用托管的 AWS 转码服务完成转码任务，以及利用开源技术实现各类计算平台的容器转码方法。
时间：9月17日 地点：上海机遇中心 二层 艺术书屋 （黄浦区南京西路 389号）
查看原文或者扫描下面二维码，了解详细会议日程和报名方法。
https://aws.jinshuju.com/f/WRpBKY
申明
本站点所有文章，仅代表个人想法，不代表任何公司立场，所有数据都来自公开资料
转载请注明出处
诞生于 2019，遇见 2020。
感谢关注，欢迎动动手指标星和置顶；
这样就不会错过少但精彩的技术探讨、团队建设、案例分享！
每周至少一更，转发是对我的最大鼓励！
学习之路漫漫，走走停停，
偶有所感，随心所记，
言由心声，问心无愧！
从客户中来，到客户中去！
