多媒体服务器架构分析
最近在研究流媒体播放的服务器,发现现在的多媒体服务器软件好贵啊!
1. 系统框架
各个厂家的流媒体系统有其自己的特色,叫法也不尽相同,但主要都可以分成四部分:媒体编码器、媒体文件存储器、媒体服务器和媒体播放器,系统架构及各部分关系如图1所示:
图1 流媒体系统架构
媒体编码器:将原始的媒体文件或摄像头采集进来的实时媒体数据制作成适合网络传输的文件格式(流格式),然后将流文件存储在媒体文件存储器中,或直接送到流媒体服务器;
媒体文件存储器:存储流格式的媒体文件;
媒体服务器:响应调度服务器从WEB服务器转过来的用户请求,通过网络传输协议将流格式的文件传到用户桌面;
媒体播放器:接收网络媒体数据,并在本地播放。
2. 传输质量控制
为了支持尽可能多的并发用户数,同时避免大量的并发用户数带来的服务器负荷加大,QoS降低的情况,要求系统对网络流量和并发用户数进行管理和限定。与该问题相关的有三个技术指标,如下表所示:
指 标
|
说 明
|
最大并发流数
|
同时连接服务器的用户数;
|
单流最大速率
|
单个用户连接服务器允许的最大速率,单位kbps;
|
最大网络带宽
|
流媒体服务器能提供的最大速率,单位kbps,一般不超过网卡速率的85%;
|
表1 传输带宽指标
一般来说,上述三个指标值关系应满足:
(最大网络带宽)/(最大并发流数)<=(单流最大速率)
不同厂家的流媒体产品对上述指标的确定方法不同。有些直接在服务器端设定,如微软最新的Media Services V9中,可以限定上述三个指标的值,也可以不做限定,依机器性能越高则相应指标越高;有些通过许可证机制设定,如RealSystemNerworks,通过购买License确定上述指标值的上限,但实际数值仍与机器性能有关。
3. 播放器架构
流媒体在播放前并不下载整个文件,只将开始部分内容存入内存,流媒体的数据流随时传送随时播放,只是在开始时有一些延迟。流媒体实现的关键技术就是流式传输,分为两种方法:实时流式传输(Realtime streaming)和顺序流式传输(progressive streaming)。
1. 顺序流式传输
顺序流式传输是顺序下载,在下载文件的同时用户可观看在线媒体,在给定时刻,用户只能观看已下载的那部分,而不能跳到还未下载的前头部分,顺序流式传输不像实时流式传输在传输期间根据用户连接的速度做调整。由于标准的HTTP服务器可发送这种形式的文件,也不需要其他特殊协议,它经常被称作HTTP流式传输。顺序流式传输比较适合高质量的短片段,如片头、片尾和广告,由于该文件在播放前观看的部分是无损下载的,这种方法保证电影播放的最终质量。这意味着用户在观看前,必须经历延迟,对较慢的连接尤其如此。
顺序流式文件是放在标准HTTP 或 FTP服务器上,易于管理,基本上与防火墙无关。
2.实时流式传输
实时流式传输指保证媒体信号带宽与网络连接配匹,使媒体可被实时观看到。实时流与HTTP流式传输不同,他需要专用的流媒体服务器与传输协议。
实时流式传输总是实时传送,特别适合现场事件,也支持随机访问,用户可快进或后退以观看前面或后面的内容。理论上,实时流一经播放就可不停止,但实际上,可能发生周期暂停。
实时流式传输必须配匹连接带宽,这意味着在以调制解调器速度连接时图象质量较差。而且,由于出错丢失的信息被忽略掉,网络拥挤或出现问题时,视频质量很差。如欲保证视频质量,顺序流式传输也许更好。实时流式传输需要特定服务器,还需要特殊网络协议,在有防火墙时有时会出现问题,导致用户不能看到一些地点的实时内容。
以往的流媒体文件格式大多采用Real Networks公司的RealMedia;Apple公司的QuickTime和Microsoft公司的Windows Media。但这些流媒体格式在使用会直接暴露出媒体文件所在的URL,而且只能提供流媒体的播放功能,无法提供用户的交互功能。所以除了以上三种主要技术外,Adobe(Macromedia)公司的Shockwave Flash技术的应用也日益广泛。Flash不仅可以提供流媒体的一般播放功能,而且可以隐藏掉媒体文件的具体URL,更重要的是使用Flash可以方便地整合用户的交互功能,而不局限于机械地播放。
现在流行的视频直播网站(比如网络电视,网络电影)一般媒体文件较大,大多采用的是Windows Media或RealMedia技术,提供实时流式传输;播客网站(比如youtube, 土豆网)大多播放的是短片,更多的采用Flash技术,提供顺序流式传输。
本文主要以Flash技术为例。
3.1. 简单的播放架构
图2 播放器的简单架构
如果多媒体服务器只需实现最简单的播放功能,那么只需在后台建立一个web服务器用于解析并响应客户端URL请求。客户端Flash播放器采用顺序流式传输的技术播放服务器的多媒体文件。优点在于网络适应性好,只需http协议即可正常工作,而且由于媒体文件会全部缓存在客户端,无论第一遍播放时网速多慢,随后都能流畅地重放;缺点不适合大文件播放,并且缓存在客户端的媒体文件存在版权等问题。
3.2. 通用架构
图3 播放器的C/S架构
如果需要保证媒体文件不会完整缓存于客户端或需要客户端播放器能整合互动功能,则需要在播放器的客户端安装是Flash通信模块,并通过一定的数据交换协议与服务器端联系。播放器的服务器端通过一个解释器把客户端的请求转换成本地应用服务器支持的服务请求。
目前可行的Flash客户端于服务器端的C/S数据交换协议大概有四种:
1.Flash Remoting
2.LoadVars(XML)
3.Webservice
4.XMLSocket
这四种架构中最好的是Flash Remoting。播放器的服务器端通过Flash Remoting来解析播放器客户端的请求,Flash Remoting实现模块很多,Adobe提供的模块有j2ee和.net两个版本是要收费的,好在网上还有两个开源的Flash Remoting模块:OpenAMF,AMFPHP。
3.3. FMS
以上四种都是通用的Flash与后台的数据交换方法,而我们要做的是流媒体通信,因此需要更专业、更高效的协议和架构。Adobe公司的FlashCom(现在改名叫Flash Media Server,FMS,已发布2.0版本)是目前应用比较广泛的流媒体播放系统,主要用于与服务端进行流媒体通信,可以支持Flash流媒体播放,Flash在线直播,Flash视频音频聊天,Flash视频会议,Flash在线游戏等。
主要特点:
u 能够实现即时视频音频通信(当然它也支持文本通信的);
u 能够流媒体同步播放(也叫在线直播);
u 能够通过Flash Player(6.0以上版本)录制视频音频,无需其他客户端;
u 能够实现客户端实现之间的控制(如会议主持人权限)。
u 不在用户端缓存视频、音频数据
u 保密的通信协议(RTMP)
u 存取控制
u SSL 傳送
u 不透露URL和媒体档案位置
FMS 因为是商业软件,代码是保密的,甚至它的通信协议RTMP也是非公开的,而且价格高昂,目前的授权价格为:
u Developer Edition 10 Free
u Professional Edition 100 US $ 4,500
u Origin Edition 5000 US $ 45,000
u Edge Edition N/A US $ 15,000
图4 小规模FMS集群的部署情况
图5 大规模FMS集群的部署
一个规模较大的视频播放系统一般要部署成集群的形式。小规模的部署如图4,视频播放客户端连接到一个Master Server上,Master Server根据负载情况把客户端链接转到Child Server上。Child Server收到播放请求时,首先从Maser Server读取视频文件并缓存在本地,然后响应客户端的播放请求。Child Server端的文件会自动和Master Server端保持同步。如果客户端连接数过多,达到单个Master/Child集群的上限,那就需要部署多个Master/Child集群(如图5)。这里,在Master Server端购买的软件就是Origin Edition版本,在Child上部署的软件就是Edge Edition版本。
如果是需要并发支持1万人,那么购买FMS的花费是多少呢?
一般说来,每个Edge服务器的并发不超过600个。那10000个并发,那就至少需要2台Origin服务器,18个Edge服务器。一个Origin服务器需要$45,000,一个Edge服务器需要15,000美金,那么总价就是:2×45,000+15,000×18=90,000+270,000=$360,000。需要更大规模的部署费用另计。
3.4. Red5
FMS尽管性能不错,但是授权费用昂贵,且无法改动接口代码。目前可供选择的还有开源的Red5(已发布0.6rc版)。
Red5是一款基于java的开源的Flash流媒体Server软件,使用LGPL协议,可以作为取代Macromedia提供的商业版本FMS。Red5使用破解了的RTMP作为流媒体传输协议,基本可以实现FMS的大部分功能。
在使用Red5实现流媒体服务器时,可能我们有时候还需要用户上传自己拍摄的视频文件,这就需要第三方软件把视频文件转成Flash可播放的flv文件格式。这可以利用FFMpeg实现,似乎Google Video也是用的它的程序作为视频转换工具。
优点:
u 由于Red5本身是基于java的spring架构,并且是开源的,在碰到问题的时候比较容易解决,大不了直接改代码;
u LGPL协议的开源软件可以用作商业用途,在成本方面也可以省下一笔不小的开销,同时为未来的功能扩展也提供了充分的空间;
u 基于java的Red5可以方便的整合当前的DFS接口和DDB接口;
u 性能据说还不错。
缺点:
u Red5作为一个开源的软件,它的性能和可靠性仍然有待检验;
u LGPL协议没有完全开放代码的修改权限;
u Red5还不支持集群部署
u 其他待补充
分享到:
相关推荐
基于云计算的多媒体网络学习平台系统架构.pdf
首先,我们提出了"媒体云"的概念,用于探讨云怎样执行分布式多媒体处理和存储,并为多媒体服务提供服务质量(QoS)配置。为了提供较高的QoS,我们提出一个"媒体边缘云(MEC)"架构,其中的存储、中央处理单元(CPU...
7.3 面向服务的架构 7.4 特定领域软件架构 7.5 基于架构的软件开发方法 7.6 软件架构评估 7.7 软件产品线 第八部分 基于构件的开发 8.1 中间件技术 8.1.1 中间件的概念 8.1.2 主要的中间件 8.2 典型应用架构 8.3 ...
因此,优先选择Sun与Blue-Siliacon为合作伙伴,以Sun ONE网络服务解决方案,建置台湾第一个多媒体讯息服务。企业可透过中华电信的hiBox系统,整合语音及数据等多媒体信息为单一讯息信箱,并以网络、无线装置和市内...
Firewalls Portal Android IOS Windows Mac OSX 服务... DMZ/US PC端 FastDFS 服务器选择适配服务 DMZ/CN Intranet 移动端 Internet 1.1 客户端多媒体消息/文件读取当前方案 信息技术架构图全文共2页,当前为第2页。 2
行业分类-设备装置-可查询下载资讯的多媒体信息服务的方法及其架构
音视频-编解码-基于IP多媒体子系统应用于下一代网络的服务发现架构.pdf
广州创亚企业管理顾问有限公司 ARM架构芯片在服务器端的发展前景 目 录 Contents 服务器的基本的概要 服务器成本构成简析 ARM芯片在服务器端的发展前景 服务器CPU国产化替代商业价值 创亚咨询 一、服务器的基本的...
基于云计算的有线电视网络多媒体业务平台的架构.pdf
信息发布系统软件及技术架构图.多媒体信息发布系统,实现信息发布,并可支持触摸功能。系统主要分为三个部分:管理平台、服务器、信息发布客户端。
用于多媒体服务的混合任播网络架构和智能服务器选择策略
IMS:移动领域的IP多媒体概念和服务(带书签完整版)一本经典的介绍IMS的书籍,该书从IMS体系架构,IMS的详细过程,IMS的协议,IMS的服务等四个方面进行了介绍。再结合3GPP的规格文档和RFC文档进行详细的学习。
新型多媒体业务云计算平台网络架构的设计与实现.pdf
首先,我们提出了"媒体云"的概念,用于探讨云怎样执行分布式多媒体处理和存储,并为多媒体服务提供服务质量(QoS)配置。为了提供较高的QoS,我们提出一个"媒体边缘云(MEC)"架构,其中的存储、中央处理单元(CPU...
首先,我们提出了"媒体云"的概念,用于探讨云怎样执行分布式多媒体处理和存储,并为多媒体服务提供服务质量(QoS)配置。为了提供较高的QoS,我们提出一个"媒体边缘云(MEC)"架构,其中的存储、中央处理单元(CPU)...
高伸缩性非常契合校园环境下的视频系统的特性。本文对于云计算技 ...构建校园环境下多媒体视频系统的底层架构。利用亚马逊网络服务, 多媒体视频系统可以有效地应对用户访问的间歇性峰值,方便视频
多媒体彩铃系统架构如图2所示。用户可以通过手机、软终端、笔记本电脑、PDA等多种终端接入并注册到IMS核心网络,SIP应用服务器、媒体服务器和数 据库协同工作,为用户提供多媒体彩铃业务。 IMS多媒体彩铃的信令流程...
AI多媒体技术在内容审核场景实践探索 安全领域智能化数据治理 低代码在业务中的探索实践 QUIC协议在分布式系统架构中的实践 Serverless设计原则有效架构选择实践 数据集成稳定性与数据质量保障及可观测实践 超扩展...
多媒体统一通讯融合平台 作者:郭嵩 来源:《无线互联科技》2015年第02期 摘 要:云计算在国内仍处于SAAS的起步阶段,但勿容置疑,这种模式将成为云架构平台上 扩展性最好、应用性最强、覆盖性最广的模式。...
天气预报、银行汇率、牌价、服务资讯、滚动字幕、紧急通知、摄像采集、电视信号传输、现场直播等 流媒体信号、数据库系统对接等网络应用。使得播放内容不再仅仅局限于已有的固定素材,让播出的内 容更加...