视频流服务架构解析

编者按：土豆网拥有国内最大的海量视频数据流媒体，截至当前，累计原创 UGC 视频超过 6000 万，每天 2-2.5 亿视频播放量，千万级用户访问行为和视频播放需求，如何能够更好地满足用户对于视频流的播放需求，基于互联网架构的流媒体服务应该具有哪些特点，未来的挑战是什么？这是本文作者李明杰要分享的主要内容。

什么是完整的多媒体视频文件？

一个完整的多媒体文件是由音频和视频两部分组成的，H264、Xvid 等就是视频编码格式，MP3、AAC 等就是音频编码格式，字幕文件只是附加文件。

要将视频编码和音频编码打包成一个完整的多媒体文件，可以有不同的方式，这种方式便是所谓的封装方式，不同的封装方式有不同的后缀。由于有些封装方式具有很强的灵活性，它可以把各种不同的音视频文件打包成一个文件，因此会出现这么一种情况，虽然文件后缀是相同的，但有些文件可以正常播放而有些却不能播放，毕竟任何一种播放软件都不是万能的。部分先进的封装方式还可以同时封装多个音频编码文件，甚至同时封装进字幕文件，如 MKV （MKV 文件可以做到一个文件包括多种语种发音，多语字幕以适合不同的人观看）封装方式。

多媒体视频文件的常见组合方式

封装格式

视频流编码格式

音频流编码格式

AVI

Xvid

MP3

AVI

Divx

MP3

Matroska（后缀就是 MKV）

Xvid

MP3

Matroska（后缀就是 MKV）

Xvid

AAC

Matroska（后缀就是 MKV）

H264

AAC

MP4

Xvid

MP3

MP4

H264

AAC

3GP

H.263

AAC

flv

H.263

AAC

f4v

H.264

AAC

表 1：多媒体视频文件组合方式

封装格式 (也叫容器)：所谓封装格式就是将已经编码压缩好的视频轨和音频轨按照一定的格式放到一个文件中，就是说仅仅是一个外壳，或者把它当成一个放视频轨和音频轨的文件夹也可以。说通俗点，视频流媒体相当于饭，而音频流媒体相当于菜，封装格式是选择什么样的容器（碗或锅），用来盛放某种视频流和音频流的组合。

视频流编码格式：

• mpeg1：早期 vcd 使用的就是这种编码格式，分辨率是 352*288，压缩比低。
• mpeg2：早期 DVD 使用，有 NTSC(720_480) 和 PAL（720_576），和 mpeg1 一样属于即将被淘汰的编码格式。
• mpeg4：目前使用最多的技术，avi 文件，大大提高压缩比，而质量堪比 4 倍 DVD 画质。
• divx：基于 mpeg4 开发的，进行了一定的算法优化。
• xvid：相当于 divx 的开源版本，也是基于 mpeg4 的编码技术更先进，采用开放源码，画质更好。
• h.261：早期低码率编码，应用于 352x288 和 176x144，现在被淘汰了。
• h.263：在低码率下能够提供比 H.261 更好的图像效果，算法进行了部分优化。
• h.263+：h.263 的改进型，亮点不多。
• h.264 ：H.264 集中了以往标准的优点，高效压缩，high profile 的压缩比例，目前最流行的编码方式。
• RV.10 RV.13 RV.20 RV.30 RV40： real 公司推出的应用于网络的高压缩编码，rm 是固定码率和 rmvb 是动态码率。

流媒体播放协议

以“流 (Streaming)”的形式在基于 IP 协议的互联网中进行多媒体数据的实时、连续传播，客户端在播放前并不需要下载整个媒体文件，而是在将缓存区中已经收到的媒体数据进行播放的同时，媒体流的剩余部分仍持续不断地从服务器递送到客户端，即所谓的“边下载，边播放”。

RTSP(实时流媒体会话协议)： 协议全称：Real-Time Stream Protocol，是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP 协议与 HTTP 协议类似。RTSP 被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把 RTSP 控制信息和媒体数据流交织在一起传送，但一般情况 RTSP 本身并不用于转送媒体流数据。媒体数据的传送可通过 RTP/RTCP 等协议来完成。

MMS（多媒体短息服务）： 协议全称 Multimedia Messaging Service，它最大的特色就是支持多媒体功能。多媒体信息使具有功能全面的内容和信息得以传递，这些信息包括图像、音频信息、视频信息、数据以及文本等多媒体信息，可以支持语音、因特网浏览、电子邮件、会议电视等多种高速数据业务，在 GPRS 网络的支持下，以 WAP 无线应用协议为载体传送视频片段、图片、声音和文字。多媒体信息业务可实现即时的手机端到端、手机终端到互联网或互联网到手机终端的多媒体信息传送。

HTTP 协议： 大众化的通信协议，在这里不做详细解释。

在线流媒体视频服务

在线流媒体的服务根据视频播放器的不同设备要求，需要输出不同的封装视频格式：

封装容器

视频流编码格式

音频流编码格式

Flash Player

HTML5 的 video 控件

PC 端 player

手机端 player

ios player

AVI

Xvid

MP3

不支持

不支持

支持

不支持

不支持

AVI

Divx

MP3

不支持

不支持

支持

不支持

不支持

MKV

Xvid

MP3

不支持

不支持

支持

不支持

不支持

MKV

Xvid

AAC

不支持

不支持

支持

不支持

不支持

MKV

H.264

AAC

不支持

不支持

支持

不支持

不支持

MP4

H.264

AAC

支持

支持

支持

支持

不支持

3GP

H.263

AAC

不支持

不支持

支持

不支持

不支持

3GP

H.264

AAC

支持

不支持

支持

不支持

不支持

FLV

Sorenson Spark

MP3

支持

不支持

支持

不支持

不支持

FLV

On2 VP6

MP3

支持

不支持

支持

不支持

不支持

F4V

H.264

AAC

支持

不支持

支持

不支持

不支持

TS

H.264

AAC

不支持

支持

支持

不支持

支持

表 2 不同封装格式的视频播放参照表

从上表的分析结果能够看到，大部分的播放器产品对于 H.264+AAC 的 MP4 编码格式支持最好，但是 MP4 也有很多的缺点，比如视频 header 很大，影响在线视频网站的初次加载时间，为了降低头部体积，需要进行视频本身的物理分段等等，所以很多在线视频网站在带宽耗费的压力下，主要选择的是 adobe 公司提供的 FLV 或 F4V， FLV 是流媒体封装格式，可将其数据看为二进制字节流，其字节编码格式为 BigEndianUnicode 。总体上看，FLV 包括文件头（File Header）和文件体（File Body）两部分，其中文件体由一系列的 Tag 及 Tag Size 对组成。

所以，为了能够提供各类设备的在线视频播放需求，对于在线视频流媒体服务，提出了很多需求，对于早期建立的视频网站（土豆，优酷，ku6 等）都只提供一种视频流媒体格式（FLV）的支持，我们称之为单一的流媒体服务架构，如图：

图 1 ：单一流媒体服务的架构图

但是，在实际业务运营中遇到了很多问题：

1） 视频存储的压力很大

同一种视频码流（h.264）, 因为针对不同平台应用设备（如表 2）的播放需求，需要不同的封装格式，需要将产生大量重复视频流存储的压力，视频网站的视频量巨大，多支持一种格式将产生几百 TB 级的存储压力，从机房到机柜，视频流同步等环节负载和压力都是巨大的。

2） 封装后的视频格式是否真的被播放

视频流封装完成后，同步到各地的中心节点后，是否真的有视频流请求产生，还是仅仅处于视频准备状态，是否会影响中心节点的磁盘占用，缓存节点的命中率不高。

3） 封装格式的功能性升级，导致老视频再次封装

封装格式的不断发展，TS 流，HTTP live Stream 的不断优化，将导致现有的视频流不断需要翻新或重复封装。 为了解决上述各类问题，视频网站流媒体服务的研发工程师进行了多格式的流媒体服务架构探索，提供了各类视频封装格式的流媒体封装反向代理接口，该接口能够通过 URL 的请求，完成对特定视频编码格式（h.264）的封装。

图 2：多格式的流媒体服务架构：

如图所示，“流媒体容器封装服务“成为多格式视频流服务的核心，对于这个流媒体的封装服务，通过对 h.264 的视频编码流进行不同格式的封装，提供了多种视频流的推送。对于这个服务，我们希望能够尽快为视频的 cache 服务推送视频流，所以，在硬盘方面，选择了每分钟 15000 转的 SAS 硬盘，降低同一视频流的不同封装请求的 IO 延迟等待。

分析与比较

作为最简单和原始的流媒体解决方案，单一流媒体服务架构唯一显著的优点在于它仅需要维护一个标准的视频流文件，而这样的服务器基础设施在互联网中已经普遍存在，其安装和维护的工作量和复杂性比起多格式流媒体服务架构来说要简单和容易的多。然而其缺点和不足却也很多，首先是维护的工作量较大，多份相同视频文件由于封装格式不相同，需要同时维护多个实体的码流文件，大量的占用磁盘的空间，再次，转码集群需要针对多种不同的封装格式，进行多次的视频转码，抢占很多资源，缺乏灵活的控制功能和扩展机制。

寄语

视频流媒体多封装格式服务目前还没有完全的开源代码，希望能够通过本篇文章引导更多流媒体服务研发人员加入到该项工作中。

感谢黄玲艳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。