基于Internet的流媒体传播平台的设计方案

现在好多地方用的到流媒体，新闻、娱乐、教育、企业都设计的到，而且流媒体未来的应用也很有前景。就目前来说娱乐上很早就有了Youtobe、优酷，都做的很成功，而且人们的生活也慢慢的离不开这些丰富多彩的流媒体，教育上，人们一直在努力的做远程教育MDE、网络教育，而流媒体之于远程教育如水之于鱼。在企业应用上，各种各样的电视电话会议系统、远程会议系统的出现，也使得企业的资源和执行力得到了极大的提高。如此看来，未来流媒体将是一个重头好戏啊。

Introduction简介

最近也在做流媒体平台的一个项目，架构的思想也看了不少，于是自己总结了一下，设计了一番，大小也算个方案吧，写下来跟大家分享一下，希望不对的地方或设计不合理的地方还请大家指正，谢谢。

项目命名为Ellipy，是一个基于局域网或校园网的直播与点播平台，简单点就两个功能：一是直播，一是点播。直播是直播像cctv这样的电视信号给局域网，点播是像优酷网给用户好多有用的资源供观看，点播又分高清和高速，采用的编码格式分别为rmvb和flv，局域网用rmvb，外网用flv。

Design设计

直播和点播的原理是不一样的，但是出于需求的原因，我们要把直播和点播整合起来。下面说明一下设计思想：

1.直播系统

现在做直播的方案有很多种，原理都很相仿。视频采集卡采集DV或其它的视频信号源，把采集的信号压缩后通过流媒体服务器把媒体信号发布出去，我所用的一套软件是Helix Producer和Helix Server，为了提高并发量和流畅，我在前端放置P2P网络，这样用户观看起来会很流畅，而其服务器负载也大大降低了。

视频采集卡->Producer->Helix->Peercast->Client

2.点播系统

点播系统的原理就更简单了，主要是通过一个流媒体服务器或Web服务器来请求流媒体文件资源，点播系统的瓶颈主要是硬盘和服务器并发量，所以服务器要有良好的硬盘支持。

文件系统->流媒体服务器->用户

3.整合直播和点播

在我们的需求里还有一个非常重要的一个功能，就是保存直播的录像视频，并转换成rmvb和flv格式，供以后点播用，而采用rmvb和flv两种格式的目的就是为了实现高清和高速的目标，在内网我可以看rmvb格式的来满足我的高清要求，在外网可以观看flv格式的来达到高速。为了实现这一目标，就需要有一个组件来转换视频的格式和监视文件，这个组件就是Core。下面看一下设计图：

上图中三条黑线标注了三个不同的视频流：

• 1.最上面一条黑线是rmvb直播流，视频信号由视频卡采集经由编码器的编码，然后通过Helix把直播点给p2p网络，用户通过p2p网络获取视频信号并观看直播。

• 2.中间一条黑线是rmvb高清点播流，rmvb文件来自核心的文件系统，经过helix服务器把该视频发布出去。核心文件系统的文件来源其一是来自编码器Producer的avi或mpeg视频，Core组件对文件系统监控，一旦有新的文件到来且需要转换格式，Core组件就会处理，生成相应的rmvb和flv两种格式的文件。

• 3.最下面一条黑线是flv高速点播流，flv文件是通过iis或其他的服务器发布出去的，用户可以直接通过http请求的形式来观看流媒体视频，也可采用rstp等协议实现。

3.1 Core组件与文件系统的设计：文件系统有三个文件夹，OriginalVideo、RmvbVideo、FlvVideo，OriginalVideo是源视频文件，其中视频文件来自用户的上传、Producer的存储、以及系统管理员的上传等，是需要格式转换的文件源。RmvbVideo是高清视频文件夹，Core组件发现OriginalVideo文件夹下有需要格式转换的文件出现时，就会把视频文件转换成rmvb和flv两种格式并存储在RmvbVideo和FlvVideo文件夹下。RmvbVideo中文件是针对高清点播的，FlvVideo是针对高速点播的。再来看Core组件的作用，从上面可以看出来，Core组件的作用就是转换视频和存储点播列表。下面列出了Core组件的功能：

• 1.监测文件系统，把文件系统中文件的状态反应到数据库上。

• 2.转换文件的格式，并标注文件状态，持久到数据库。

• 3.生成点播列表。

• 4.为后台管理提供接口，比如制定转换计划、改变转换参数、文件管理、点播列表管理等。

4.”分布式"系统

现在好多软件或网站都讲究分布式或SOA，要求的无疑就是高性能和高方便性，我的这个设计也可以很容易的就做到分布式，而且需要的变动很小，可以很容易的就扩展到多台机器上，也许一开始我们没有足够的资本去部署好几台服务器，而后来随着业务的需求慢慢的用户数增多了，硬件满足不了需求，或是一个系统的多个组件对系统的资源形成征用性依赖，那么把系统做成分布式就非常有不要了。下面我们看看系统是怎么变身的：

图中的三条横向虚线代笔了服务器的分割线。

在上图中我们看到了跟部署在一台服务器上是有区别的，变化在哪里呢？

• 1.直播系统和点播系统各自维护了一个自己的文件系统。

• 2.直播系统、点播系统的文件系统通过适配器Adapter与核心文件系统的Apapter交互。

可以看到，变化很小就实现了直播系统和点播系统的分离。直播系统的硬件需求是视频采集卡、流媒体服务器平台，Core核心部分对CPU需求较多，因为它要进行格式转换，点播系统对硬盘依赖很大，因为点播的瓶颈的大量的对硬盘的读取和IIS并发量。这样也做到了系统资源的分布式。

下面说一下变化的工作原理，先定义几个"变量"：A 直播和高清点播服务器（图中最上面一块）  B 核心文件系统服务器（图中中间一块） C 告诉点播服务器（图中最下面一块）

• 1.增加两个独立的文件系统：增加两个独立文件系统的作用就是让各自需要的文件类型都储存在自己的机器上，减少服务器间流量，保证服务器间有效通信。

• 2.Adapter设计：纵观整体设计，我们发现不管是高清点播还是高速点播，对一个东西非常感兴趣，在收集直播视频时，也对这个东西感兴趣，这个东西就是“文件”，那么我们就把文件分离出来，编码器采集视频源到文件系统生成mpeg，Core组件对mpeg视频进行转换成rmvb和flv，高清点播读取rmvb，高速点播读取flv。“分布式”系统后，直播和高清点播部署在一起A，他们的文件系统的作用就是收集Producer的mpeg视频，A的Adapter同步B的rmvb视频（它对flv视频不感兴趣，因为它提供高清点播服务，flv不是高清视频），C的Adapter作用是同步B的flv视频文件（它只对flv文件感兴趣，因为它追求高速，对高清嗤之以鼻）。B的Adapter的作用就是同步A的源文件。

这样就实现了分布式的部署，是不是很Cool啊！

Summary总结

1.本设计的代码还在进行中，还不能确定潜在的问题，欢迎大家提意见。

2.对视频文件格式转换的软件多用ffmpeg+mencoder这两个工具。

3.本系统在做大型CDN的时候有缺陷，不适合做大型CDN系统。

4.如有不正确的地方还请大家指正。

作者：Creason New(Creason's Blog) 
出处： http://www.cnblogs.com/niuchenglei 
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。