本文为Hulu高级软件开发主管李彬2015年在TOP100全球软件案例研究峰会上就“Hulu全平台视频系统的演进”做的演讲。
技术选型之路
Hulu的视频系统基本上分为三个主要的发展阶段：
第一阶段：基于Flash的视频系统
与国内外视频服务最开始的视频系统类似，Hulu最早的视频系统也是基于Adobe Flash插件的。Flash插件为Hulu提供了在浏览器中进行视频播放的能力。这一能力在Hulu早期提供了相当的竞争优势。 Hulu的视频服务直接打开网页就可以访问使用，而当时的一些竞争对手，比如Joost，则还需要安装一个桌面的客户端才能使用。Hulu的使用便利性更高。另外，直到今天，虽然Flash不时爆出一些严重的漏洞，但它仍然是唯一一个跨越几乎所有桌面系统的所有浏览器的应用平台。虽然在Web方面Hulu已经开始向HTML5 播放器演进，但在很多老浏览器中，基于Flash的视频播放器仍是唯一的选择。
围绕Flash插件，Adobe公司有从上游到下游几乎完整的解决方案，视频服务器使用Adobe Media Server，视频格式采用VP6/MP3 + RTMP(E)，终端使用Flash插件播放。唯一的问题是，Flash插件在移动设备（iOS, Android），客厅设备上的覆盖率不高，要支持这些设备，则必须增加系统中的视频格式及相关后端工作流。
第二阶段：HLS+H264为主，多平台，多格式视频系统
从Hulu Plus正式发布开始，移动设备和客厅设备上的视频服务越来越成为Hulu服务中的重头戏。而正是因为Flash插件没能在这两类设备上广泛铺开，必须增加新的格式以服务这些平台。其中Apple 的HLS（HTTP Live Streaming）格式在这一时期是最常用的格式，因为HLS是iOS设备上支持最全面的视频封装格式。
这一阶段发生的另外两个趋势是：
1. 视频／音频编码格式从VP6/MP3升级为H264/AAC。H264解码器在各种设备上的广泛存在，真正使得编码一次，在所有地方均可播放成为可能。所以Hulu也开始启用H264格式。直到今日，大部分的Hulu视频仍是采用H264编码的。
2. 我们的内容提供伙伴对DRM开始提出更高的要求，要求Hulu上播放的视频流必须是通过DRM保护的。这时，各大公司开始推出自己的DRM解决方案，但是这些方案之间互相独立。一个视频如果需要通过不同方案播放，则必须用不同的加密方式进行加密。
正因为这两个趋势，一方面在数字视频供应链方面，采用H264大大简化了视频系统的工作流，每个视频在每个Profile下，只需编码一次，不同封装则可共用编码的结果。而另一方面，由于封装和DRM加密的不同，一个视频需要存储多达上百种不同视频格式。这样视频存储及CDN分发的成本也非常大。如果要新上一个全新的设备，则往往需要重新封装，加密几乎所有的视频。造成上线的延迟。
第三阶段：基于MPEG-DASH的视频系统
2013年，业界出现了借鉴Apple HLS，Adobe HDS （HTTP Dynamic Streaming），以及Microsoft SS（Smooth Streaming）的MPEG-DASH格式。DASH是（Dynamic Adaptive Streaming over HTTP）的缩写。它结合了HLS，HDS，SS的优点，同时又基于IOS，MPEG有关视频封装、加密的标准。虽然DASH没有像HLS 那样快速在业界获得广泛应用，但是由于其借鉴了之前类似协议的优点，同时更多的基于工业标准，不但有各方面更好的性能（如高封装效率，可适应网络带宽变化，支持内容，广告之间的快速切换等），而且无论是在前端播放器，视频服务器还是后端视频处理流水线都可以获得标准、公开接口、开源函数库的支持，从而易于实现及集成。
DASH最基本的比特流基于标准的MP4格式（ISO/IEC 14496-14），但是与传统的moov+mdat格式不同 ，DASH采用了分段格式，除了在一个完整视频内容前端的moov头，之后的视频数据在GOP边际被封装在若干个moof+mdat的分段内。这些分段可以独立访问及渲染，类似于Apple HLS标准中的TS分段。这些分段以小文件方式通过CDN发布，也可以像传统的MP4文件一样，一个大文件整个进行发布，相比HLS大大减少文件数目，降低CDN分发成本。以下图显示了整个视频文件的格式，及每个分段的格式
图 2 DASH文件比特结构：a) 整个视频文件的格式，a) 单个分段的格式
Hulu在DASH比特流上有一个有意思的创新，在Hulu开始支持DASH格式之前，为了支持Windows及Xbox设备，我们已经支持Microsoft SS格式，由于DASH的比特流的加密格式与SS一样都是基于微软的PIFF标准的（Protected Interoperable File Format）。所以用于SS的文件实际上与DASH是相同，见下图。用于SS的视频文件同样无需重新封装，加密即可用于DASH。这一创新减少了我们需要支持的文件格式，降低了成本。
图 3 与Smooth Streaming兼容的DASH格式
在比特流之上，DASH采用了XML格式的媒体文件声明格式，称为MPD（Media Presentation Description）。MPD类似于HLS中的m3u8文件，同时更为灵活，支持MP4及M2TS文件格式，同时比m3u8效率更高，只需一个文件即可描述多个音视频轨。MPD直接索引相关的视频文件链接，除了采用最基本的文件列表方式（SegmentList），同时还支持文件模版方式（SegmentTemplate），以及直接利用mp4文件中的索引（SegmentBase）。MPD还保存了除了文件索引还保存了编码及DRM的相关信息。一个典型的MPD文件结构如下所示：
图 4 MPD文件结构示意
Hulu的许多关键功能，如单视频文件多DRM支持，动态广告插入，多码率视频自动切换都可以基于DASH实现。我们现在计划的一些新功能，如4K，虚拟现实，多音轨视频等也都可以通过DASH很好的实现。另外DASH大大降低了我们视频系统的运营成本，使得原本需要编码封装上百种不同的格式，变为只需为每个视频码率，编码封装一次。在CDN上也只需保存一份拷贝。
早在2013年末，Hulu就基本完成了视频工作流及视频服务中对DASH的支持，并在ChromeCast设备上率先上线基于DASH的视频服务。经过几年的发展，目前DASH已经在Web，Android，FireTV，AndroidTV，Roku，PS3/PS4，Wii，其它多种Settop box及Smart TV上实现了基于DASH的视频服务。再此基础上，我们还在不断做各种前后端优化，提高用户体验，并将在更多的新业务中采用以DASH为核心的视频系统。下面是Hulu基于DASH的视频系统的基本架构介绍。
视频系统的架构
基于DASH的视频系统的一个核心思路是简化视频后端的逻辑，把更多的智能放在客户端来实现。这样后端服务的目的明确，功能简单，易于管理，优化及扩容。同时客户端适应性更强，更容易在更多的设备上进行集成。在此基础上，为了能更好的监控整个系统的运行状态，我们架设了独立的QoS（Quality of Service）监控体系，随时监控各种关键指标，如观众数目，播放器缓冲比例，内容／广告加载速度等等，并实时调整后端的规则及参数，从而快速响应运行状态的变化。整个系统的示意图如下所示：
图 5 Hulu视频系统整体架构
以下是视频支持系统中的内容服务系统架构：
图 6 内容服务系统架构
以下是服务监控系统的架构：
图 7服务监控体系系统架构
以下则是前端播放器的程序结构：
图 8 前端播放器程序结构
所有这些系统，组件协同工作，稳定，高质，高效的实现了Hulu现有的视频服务。
总结
Hulu的视频系统在某些方面和国内的视频服务同行大同小异，某些方面则有自己独特的一面。归根到底，Hulu是从商业、产品的需求出发，根据我们拥有的资源最终制定的解决方案。基于DASH的视频系统基本上可以说完美的满足了我们对视频服务支持上现有的的各种需求，并对将来的升级，扩展留有较好的扩展空间。Hulu会继续在MPEG-DASH方面进行投入，并参与到未来标准的制定中。目前DASH在国内同行中使用和了解的人都不多，希望这次分享能促进这一具相当潜力的标准在国内更广泛的认知和使用。
脱开介绍的特定系统，从架构选型的角度考虑。我觉得Hulu在技术选型，架构规划方面也有一些值得借鉴的地方。首先正如一开始说到的，在自建或者购买的选择中，Hulu从一开始就强烈的偏向自建，这样虽然最初的成本会更高，但是会使公司对技术架构有更全面、牢固的把握，有利于系统的长期维护及升级演进。而在另一方面，Hulu对于开源软件，业界标准是全面拥抱的姿态。我们在自己的系统及组件中广泛使用开源软件，在设计系统的时候也尽量围绕业界标准（比如视频系统中的MPEG-DASH标准）。这样设计出来的系统，初期实现起来更容易；中期维护可以参照很多业界经验，维护成本较低，同时也更容易和其它系统进行集成；而后期则更容易跟随业界最新的技术发展趋势进行升级。而在跟随开源软件、业界标准的同时，Hulu同时进行了很多自有的创新，这些创新反过来又回馈开源社区及视频业界，从而形成了公司与业界相互促进的良性循环。
下一步，我们将继续在视频系统方面进行不断的优化和创新，毕竟新的需求在不断产生，新的视频体验还等着Hulu去探索，比如4K，5.1声道，虚拟现实等等。我们会致力于我们对用户的许诺，为用户提供“A seamless experience across all your devices”。
版权声明：本文系Hulu北京办公室独家稿件，转载须注明来源及作者，否则必将追究法律责任。