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

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

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

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

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

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

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

视频流编码格式：

流媒体播放协议

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

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

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

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

在线流媒体视频服务

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

表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延迟等待。

分析与比较

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

寄语

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