2.2 全真武功：Helix

为同DirectShow分庭抗礼，支持自家不同产品线的开发，Real公司在20世纪90年代重金投入，打造出一个别有特色的多媒体框架Helix。使用Helix框架打造的包括许多业内耳熟能详的产品，如RealPlayer、Helix Server（即Real Media Server）、Helix Producer、Helix Broadcaster等，虽然市场地位早已今非昔比，但直至笔者离开Real公司的2015年，基于Helix技术打造的部分产品仍保有一定的技术先进性。

2.2.1 产品系列

稍有几年网龄的朋友应该都对RealPlayer并不陌生，作为早年大为流行的播放器，它初始以优良的播放质量闻名，后又不断添加各种功能，如应用内的转码工具、视频点播、广播电台、网络视频下载插件等。2013年，Real公司曾推出与RealPlayer整合的RealTimes功能（见图2-7），支持将用户的所有私人图片与视频进行云端存储并自动生成剪辑，希望切入社交领域，但未能成功，同时商业模式不明确，又没有深度学习加持的视频剪辑功能也很快被Google Photos等各家竞品轻松超过。

Helix Universal Server又称Helix Media Server，是以高性能、跨平台著称的流媒体服务器，主打直播和点播流的传输，开发了许多适合CDN服务的功能，早年在Akamai等公司的CDN网络中被广泛运用，并启发了许多现代高性能HTTP服务器的架构设计，其主要技术后续将在流媒体服务器章节进行专门介绍。

Helix Producer是基于Windows平台的专业转码工具，其免费版即Real Producer（见图2-8），很多国内的字幕组都将此工具作为日常使用，压缩出添加字幕、经过剪辑的RM或RMVB视频文件。Helix Producer与免费版相比较，除支持更多的格式外，主要增加了对专业视频采集卡的支持，各种滤镜、音视频编辑、台标嵌入等功能，以及与其他Helix产品的整合。

Helix Broadcaster是2013年RealNetworks推出的集多路编码和分发功能于一体的硬件设备（见图2-9），借助Helix框架在编码与流媒体服务的优异特性，Helix Broadcaster目标是打造成编码器领域的Wowza，提供当时业界最为丰富的功能集和超高的性价比，十分适合在线视频，可谓Helix框架最后的荣光。

2.2.2 设计架构

Helix框架与DirectShow既有许多相似，又有大量不同。在2006年，Helix框架被部分地开源，整体代码分为Public（公开）、Private（私有）和RN（公司自有）三部分，其中Public部分包括所有免费产品使用的代码，任何人均可下载、修改和使用，Private部分则提供了较多的功能，为公司的合作方提供服务，根据不同合作方又有不同的分支及功能，RN部分则完全保留了Real公司的私有技术，所有商业版软件均包含以上三部分内容。

Helix使用C++语言，创造了类似COM的组件技术，除了应用的核心模块和底层支持库外，组件通常以插件形式存在。由于框架定位不同，任何功能均被写作为插件形式，Helix的插件类型远远多于DirectShow，其中包括一个类似WPF功能的UI引擎，拥有类似XAML的标记语言以创建UI，一个包含常用数据结构、内存分配、异步I/O、加解密、线程池、汇编加速函数集在内的完整基础功能库，以及可将插件自由组合成产品的跨平台编译和链接系统。

Helix插件的撰写与COM程序类似，需要实现QueryInterface接口，每个接口存在一个REFIID类型的唯一ID，使用插件的人可以根据ID从插件上Query到所需的接口并调用，不同的插件可以实现相同的接口，每个插件也可以实现多个接口。当插件开发完成后，只需要定义一个.upp文件，其中描述了形如下述的模块，依赖的宏定义、头文件等信息，并在产品的完整设置中注册，即可被编入应用中。

和其他多媒体框架一样，Helix的主要功能是对音视频文件或流进行处理，在命名上与其他框架有所不同，其中解析文件和封装，命名为De-Packetize和Packetize。较为彰显特色的是，Helix对于文件和包格式也进行了组件化，即File Format插件和Payload插件，而不仅仅是针对处理过程进行抽象。此外，对于基于Session的流媒体协议有较复杂的，由多个插件协同工作的机制设计。

2.2.3 特色技术

不同于DirectShow和后面要介绍的FFMpeg、GStreamer等框架，Helix框架的名气并非来自开发者，而是完全依赖几款重量级产品在产业历史上占据一席之地，支撑这些产品的，除了前文已有描述的RM、RMVB、RV、RA等文件与编码格式，尚有许多曾经走在时代前沿的特色技术，以下将择要进行介绍。

Sure Stream、RDT、RBS Real公司首先实践了Sure Stream（确定流）技术，即在一个文件或直播流内包含多种不同码率的音视频流，并在流媒体协议中探测播放器的带宽情况，选择不同的码率发送给播放器。RDT和RBS都是Real公司的私有协议，RDT还有公有的替代方案（即RTP和RTCP），但由于RDT允许在一个流上同时传输音频和视频等不同信息，XAML是WPF所依赖的UI描述语言。

因而它有着比RTP/RTCP更好的性能。RBS则完全用于在Real公司的产品之间发送直播流，它是基于UDP的轻量级协议，几乎没有冗余的信息。例如，解码器所需的参数信息在编码器、服务器和播放器之间均以二进制传递，除带宽节省外，还可以避免序列化和反序列化的时间，有着极高的性能。

RSD（即Reduce Startup Delay，降低启动延迟）是一项针对RTSP或RTMP协议流媒体传输时优化启动时间的技术，因为播放器在开始播放前需要得到足够的缓冲数据，且播放需要从关键帧开始。由于在服务器中直播流存在一定长度的缓冲，当客户端发起请求时，服务端首先将保证从关键帧开始发送，而非简单地发送所持有的时间戳最早的包；其次，服务器会在发送初期按照3倍速率发送，以帮助播放器尽快填满缓冲区，开始播放。点播场景中的思路相似，服务端将在指定播放位置附近找到最近关键帧再行发送。

另一项与之相关的技术称作Fast Channel Switching，即快速频道切换，当播放器意图切换点播节目或直播频道时，其与服务端之间建立的连接并不销毁重建，而是复用已存在的Session，服务端从新节目的关键帧开始加速发送，可以避免重建播放会话带来的屏幕中断，并达到最快的节目切换。

Live Low Latency译为直播低延迟，对于直播服务而言，一项重要的直播是它的时延。例如体育直播，人们不希望在地球彼端的球赛进球已经许久的情况下本地才看到对应的信号，早在2004年的纳斯卡赛车直播中，Real公司就已经在互联网上部署了端到端延时仅为4s的流媒体服务，而Live Low Latency技术则可以进一步压榨延时性能。

Live Low Latency的技术原理并不复杂，Helix服务器支持多级级联，原本从每一级的服务器到终端的RealPlayer，各个环节上默认都有1～3s不等的缓冲。使用LLL技术时，服务器和播放器都会取消缓冲，并丢弃超时到达的音视频帧，保证时间线与原始时间线尽量接近，这项技术和RSD技术存在冲突。

Rate Control译为码率控制，这是一项专利技术，其目的是调整服务器向客户端发送数据的速度，以保证播放器播放的连续和保持合理大小的缓冲，服务器利用RTCP，通过评估客户端的请求到达时间和包丢失率来建立模型，推断网络状况。算法灵感来自于MIT在2001年的论文Binomial Congestion Control Algorithms和2003年的RFC3448TCP Friendly Rate Control。

Server Side Playlist即服务端播放列表，这项技术主要用于广告插入，允许在服务端通过编辑播放列表的方式对点播和直播流插入广告，因为支持通过API动态加入和删除播放列表，广告插入的决定可以无限接近实时。

此外，Helix框架还曾提供服务端码率切换、Cloaked RTSP（隐匿的RTSP，用于防火墙穿越）、HTTP连接统计等诸多特有功能，或比市场上的竞争对手提前多年，或性能大幅超出。让人想起在金庸的武侠小说中，王重阳曾号称天下第一，建立玄门正宗的全真派，不论内力、剑法还是阵法，均有出彩之处，但习练之人功夫不到，每况愈下，Helix框架如同全真武功一样，其影响力的衰落令人惋惜，只能活在传说之中。