在火山引擎云产品发布会「预见趋“视”」分论坛中，得到多媒体中心负责人张恒带来了题为《得到：火山引擎助力知识更好传播》的分享。
得到App在线上的知识服务，以“课程”、“每天听本书”、“电子书”等知识产品为主要交付形式，并为用户提供了知识搜索、知识城邦社区、直播授课、个性化推荐等功能内容。
得到多媒体中心负责人张恒
张恒分享了火山引擎视频云团队如何助力得到APP音视频体系相关能力建设，支撑知识服务产品更好发展，并讲解得到多媒体团队如何通过视频云技术更好提升用户体验。
以下为演讲实录：
大家好，我是得到技术团队的张恒，负责多媒体技术工作。非常荣幸受邀参加火山引擎的云产品发布会，同时我将以“火山引擎共创者”的身份，与大家分享我们眼中的火山引擎是一个什么样的团队、火山引擎是如何助力知识更好传播的。
音视频技术在当前的互联网应用中已经是不可或缺的基础设施，听一段音频、放一段视频、打一个网络电话，这几乎是每个人每天都会做的事情。我在2017年加入得到，见证了得到App这些年的发展和变迁。熟悉我们的人都知道，几年前，得到App上的内容承载形式主要以音频为主。我们将萃取的知识，以口语的形式、音频的方式交付给用户，后来我们站内有了视频和直播。
我全程主导、参与了得到音视频的支持体系，从开发Android和iOS端的播放器、自研DRM方案、播放质量采集和分析工具链，再到音视频中台化建设、音频资源响度统一，后面还做了音频数字水印设计、直播间建设等等。所以无论是我个人还是我的团队，已经在音视频技术领域有了一定的了解和积累。
火山引擎是一个什么样的团队
在聊我们第一次和火山引擎打交道之前，我简单讲一下项目背景。得到App里面有很多学习特别认真的用户，而手机屏幕的尺寸限制了他们的使用。今年初，我们准备将得到App的功能移植到桌面浏览器当中，方便用户通过键盘记笔记、通过大屏幕使用。
从规划评估到产品设计，遇到的第一个问题，是我们无法在Web环境实现DRM（数字版权管理），不能有效保护我们的资源、避免被滥用。内部调研了方案，也咨询了很多供应商，但Web环境的DRM功能并不是特别受重视。而对于我们而言，这意味没有保护的资源会成为全站的短板，这是完全不能接受的。
请允许我简单介绍一下构成当下流行的WebDRM三大生态：苹果Safari浏览器的Fairplay、谷歌Chrome浏览器的Widevine、微软IE浏览器的PlayReady，他们背后的生态系统主要是iOS、Android、Windows，他们相互割裂，互不兼容。我们之前尝试去和三个厂商直接沟通，但周期长、成本高。同时也考察过国内的供应商，很难做到全覆盖。除了使用浏览器生态的三大框架之外，还有一种选择，是使用WebAssembly封装密钥保护和加解密模块，配合使用H5的媒体源扩展(Media Source Extensions)，实现私有化DRM的方案。
火山引擎的WebDRM成就了第一次接触
今年4月份，得到Web版正式列入日程，计划于6月18日上线。我作为得到多媒体技术的负责人，需要在一周内给出解决方案。面对这个挑战，我开始有点焦虑了。4月28日，我们以“打听一下”的态度找到火山引擎，并于第二天进行了首次的在线会议沟通。简单沟通之后，确认了一下DRM细节，正是我们想要的私有DRM方案，这让我看到了希望，抱着试一下的心态，我们决定先试用体验，约定五一之后的第二个周一再次对接。
在试用阶段，核心功能很快就验证通过了，但是Web播放器的支持并不完整，还发现不少不合理的地方。 刚开始对接的时候，我们发现了一个关于DRM的安全漏洞，存在可能的中间人攻击，没有实现严谨的数字信封流程。过程是这样，我这里画了一张DRM访问的流程图，这张图是简化过的，本来DRM的过程还挺复杂的，这里挑重点画，主要是方便给大家讲。第一步，是由App的业务层发起，向业务服务发起请求，验证当前用户对点播的内容是否有权限。正常返回一个播放凭证，用于对接火山SDK。接下来的事情就交给火山SDK了，第二步，由火山SDK向点播服务发起获取点播信息的请求，对方返回播放地址和时长之类的元信息。然后，由底层的安全模块，去DRM服务验证点播授权，会返回用于解密的授权license。最后播放器SDK会按照播放地址去CDN获取数据流。最终，由安全模块按照给定的解密授权去解密媒体流，交给播放器去解码。
这个流程有什么问题呢？简单说，当第一步结束之后，我换个集成了火山SDK的播放器，照样也能播放，这样就可以跳过我们的App服务验证，让没有权益的播放成为可能。
当时我听说Web DRM功能是火山引擎首次对外输出，得到算是第一个客户，此外有这方面诉求的客户也比较少，这个问题让我比较忐忑。
但当我在沟通会上提出了相关疑问后，火山引擎的同事立刻召集相关的安全专家进行评估，并组织一个项目组进行调整，拿出改进方案。让我们感到意外的是，火山引擎团队会反复和我们核实、征求我们的建议，充分尊重和信任合作伙伴。与字节跳动相比，得到只是个成长期的公司，但在整个项目对接的过程中，火山引擎的团队从来不会因为公司大小而影响他们的工作程序，对于我们提出的问题全部都会认真排查。
“被火山引擎撵着跑，说啥也不能掉链子”
我们在接下来的一个月里面反复沟通，沟通点包含功能诉求、性能指标等等。让我感到意外的是，每次和火山引擎团队沟通之后，他们都会记录详细的会议纪要，并且形成完整的TodoList，当我第二天打开文档，就会多一些新的内容，不仅有讨论，还有备选方案的对比。当我第三天打开，又会补充排期和责任人，这个过程是全部透明交付给我们的。更让我意外的地方，是对方经常来推动我们，问我们这边的进展、进度，追着我们做验收。我们内部经常说：“这次咱们是被火山撵着跑，咱说啥不能掉链子啊。”
得到Web版的接入工作在6月18日如期上线，没有延迟，并且上线之后，至今也没有影响体验的负面反馈。我意识到在这次合作中，我们真正成为了火山引擎视频云的“共创者”。
这个项目收工了之后，我们的产品经理想在得到App中投放一些轻快的内容，通过短视频提升内容的分发和曝光，毕竟短视频是这个时代大家最喜闻乐见的形态。当决定要做的时候，我就跟产品经理沟通需求，当我问到做短视频想要做成什么样子时，产品经理的回复非常简单明了，只说了几个字：和抖音一样。对于这样的要求，我一点也不意外，此前与火山沟通时，曾提过这一部分。于是我信心十足当场回复说“没问题，全面对齐抖音，音视频接入不是短板，出需求文档吧”。
其实我们站内是有自研播放器的，但是要优化到和抖音短视频一样的播放体验，况且要求各种指标直接对齐，短时间内我没有把握。我没有过多考虑，直接选择了使用火山VodSDK进行短视频接入。
决定之后，我们和火山团队立刻沟通了起来，我自认为给火山引擎提出了很高的要求，属于“既要、又要、还要”，而且各项指标还要对齐抖音。但是火山引擎团队非常配合，全面支持，这些挑战最终都被火山引擎一一化解，项目如期交付上线，这让我深刻体会到站在巨人的肩膀上感觉真好，这样我们可以更加有力地支撑业务的发展。
如上就是我们最近半年跟火山合作的两个项目的情况，谢谢大家。
