流媒体服务器（精选12篇）
流媒体服务器 篇1
基于代理服务器的缓存 (Proxy Caching) 技术最初是用在WEB内容的分发上, 通过将经常访问的WEB内容 (网页文本、图片、动画等文件) 存放在接入网络边缘的代理服务器上, 有效地节省了骨干网络的带宽, 缩短了用户的响应时间。近年来, 随着多媒体点播应用的日益普及, 多媒体内容的传输占用了当前Internet上的大部分流量, 导致骨干带宽紧张和用户接入时延增加, 代理缓存正是缓解这一矛盾的有效技术手段。
1 前言
相对于传统的web对象 (如HTML页面和静态图像) , 流媒体对象所具有的数据量大和对带宽需求高等特性需要对现有的代理缓存策略进行充分的拓展。为了缩短客户端的启动延时, 一个有效的方法就是在靠近客户端的代理服务器上缓存被频繁访问的数据。这种方法缩短了传输的距离, 提高了对象的可用性并降低了丢包率。
流媒体代理服务器缓存是一种内容复制技术, 利用缓存的流媒体内容服务访问的用户, 代理服务器位于骨干网和企业网之间, 能够通过转发操作向局域网内的用户提供互联网的访问服务。同时, 面对庞大的互联网单个代理服务器的缓存效果比较有限, 可以考虑多个代理服务器协同工作的流媒体缓存形式。
流媒体代理服务器的功能如下:
管理部件:负责与用户、服务器进行协议交互;在响应访问的过程中决定是否缓存内容或者能否利用缓存内容直接服务用户访问;
存储部件:包括缓存空间和保存内容、缓存替换、缓存查询等空间管理操作。具体涉及缓存空间的组织方式、缓存内容的选取过程、释放内容的选择、释放动作的执行等内容;
发送部件:负责完成实时数据的接收和发送工作。并需要根据传输情况将转发的数据包再进行重组或转发。
2 缓存算法分析
2.1 滑动区间缓存
这类算法缓存了一个媒体对象的滑动区间, 并使用它对流媒体进行连续的访问。典型算法包括:Interval Caching、Resource-based Caching。
间隔缓存算法 (Interval Caching) :如图1所示, 对于相同对象的两个连续请求, 第一个请求从服务器获取对象并缓存在代理当中, 第二个请求可以从缓存当中获取数据并随后释放。如果两个请求到达的时间间隔很短, 那么只有很小的一部分媒体对象数据需要被缓存, 并且第二个请求完全可以从代理获取完整的服务。如果在一个很短的期间内对于一个对象有很多的请求, 那么这些相邻的缓存间隔可以被组织起来, 直到最后一个请求得到满足之后再释放被缓存的部分。
基于资源的缓存 (Resource based caching, RBC) 算法:将Interval Caching部署于代理服务器的磁盘中。由于磁盘的容量比内存大得多, 为改变间隔缓存的存储粒度提供了足够空间。RBC算法以每个媒体对象对缓存空间和传输带宽的需求为约束条件, 提出了一种启发式的算法对媒体对象的缓存粒度进行选择。依靠对象的特征和可用的资源, 被选择出来的粒度可以是一个滑动间隔, 一系列邻近间隔的组合, 或者是完整的媒体对象。
基于间隔的缓存适用于用户请求具有高度的时域邻近性 (Temporal locality) 的情况, 此时间隔缓存可以显著的降低网络带宽消耗的峰值和连续请求的启动时延。然而, 当用户请求的分布在时域上稀疏时, 该算法的有效性就会随着到来请求间隔的增长而降低。
2.2 前缀缓存算法 (Prefix Caching)
前缀缓存在代理服务器上缓存流媒体对象的起始部分, 叫做前缀。由于前缀部分可以直接从代理服务器获取从而有效降低了客户端的启动延时。在提供前缀服务的同时代理服务器从原始 (内容) 服务器上获取其余的后续部分 (叫做后缀) 并转发给客户端, 进而节省了部分骨干网带宽并保证了播放的连续性。对于前缀缓存策略, 前缀部分的大小和分段方法是决定系统性能的重要因素。前缀缓存在运行期间的缓存状态如图2所示。
前缀缓存算法是目前应用最为广泛的流媒体缓存技术。其不足之处在于媒体前缀部分的长度不容易确定, S.Jin等人的研究[5]表明, 在有限的网络资源的约束下, 为达到指定的启动时延的前缀缓存的部署是一个部分背包问题 (Fractional Knapsack) , 需要贪婪式的优化算法来解决。
2.3分段缓存算法 (Exponential Segment Caching)
分段缓存推广了前缀缓存方法, 将媒体对象分割成一系列的段落, 并根据它们各自的效能来决定是否缓存。不同的分段缓存算法具有不同的分段方法和效能计算方法。将媒体对象按照统一的大小进行分割, 一个媒体对象分割不同尺寸的段落, 长度根据与媒体头部的距离按照指数方式增长, 段i的大小为2i-1, 包含2i-1, 2i-1+1, …, 2i-1帧 (如图3) 。采用指数划分的分段策略可以通过丢弃大的后续片段快速获得足够的磁盘空间, 达到适应用户请求变化的目的。媒体片段的利用代价定义为片段被访问的次数除以其距离媒体起始片段的距离, 因此具有更高访问频率的初始片段将优先被缓存。
分段缓存的一个显著特征是它支持VCR类的操作, 如随即访问、前跳和后跳。当客户请求对象时, 代理首先分发热点部分来提供对于流的纵览, 客户可以决定是播放整个流还是快速跳到由热点引入的一些特殊部分。此外, 快速的前跳和后跳操作, 只有相应的热点被传送和显示, 而其他部分被掠过。同样, 服务器的负载和骨干网都会因此大幅降低, 而客户不会错失媒体对象的任何重要段落。
2.4 速率分裂缓存算法 (Rate-Staged Caching)
上述缓存算法是按照时间轴来分割媒体对象, 而速率分裂缓存则按照速率轴来分割对象。速率较高的部分被缓存在代理上, 速率较低的部分仍然保留在原始服务器 (如图4) 。速率分割缓存方法非常适用于VBR流, 因为只有较低的接近于恒速的部分通过骨干网络被传送。在代理服务器缓存高速率的部分能够明显降低速率的变化并提高骨干网络带宽的利用率。速率分割缓存当中一个值得探讨的问题是如何选取切断速率和高速率部分的大小。实验证明利用一个相当小的缓存空间就能够明显降低带宽。
3
算法性能比较 (见表1)
4针对不同类型用户的缓存算法
以上算法均为同构网络环境下的代理缓存算法, 但由于接入网络和设备配置的不同, 用户往往对同一流媒体对象在速率或编码格式等方面有不同的要求。为了适应这些非同类的客户, 最直接的方法就是对不同速率或格式生成多个副本, 每个针对一类用户, 但这种方法对服务器的存储要求极高。另一种方法是进行代码转换, 将流媒体转换成更低速率或不同格式, 但这需要大量的计算开销, 使代理服务器不能支持太多的用户。更有效的方法是使用分层编码和传输, 客户可以获取部分层次, 重构出与其能力相匹配的流媒体。
分层缓存将原始媒体对象压缩成几个层, 最重要的层叫做基础层, 包含了表现对象最重要特征的数据, 附加层也做增强层, 包含的数据可以用来逐渐提高质量。客户可以根据它的能力预定累积层的一个子集来重建流 (如图5) 。对于分层缓存, 假定被缓存的部分是半静止的, 而完整的层被缓存。为了最大化整体收益, 采用基于随机背包模型分析的有效的启发式算法来确定缓存的内容。对于动态环境下的分层流, 采用基于分段的缓存替代和预取方案, 来获取缓存空间和可用带宽的有效利用。主要的目标是要处理个体客户的拥塞问题。代理将跟踪每个对象的每一层为基础的流行性。当被缓存的层的质量低于可以向客户端传送的最高质量时, 代理使用一个滑动窗口向服务器申请缺失的段落。缓存替换时, 一个牺牲的层依照流行度来确定, 缓存的段落被从尾部开始释放直到获得了足够的空间。
5 展望
代理缓存可以有效降低流媒体分发时的用户体验时延和骨干链路带宽需求。本文主要针对同构网络用户, 对现有的各种流媒体代理缓存策略进行了分类比较。
流媒体代理缓存技术除了自身仍然面临着众多的选择和折衷, 在其他很多方向上还有很多问题有待解决。
现有的缓存策略的研究都是将Web对象与流媒体对象分开考虑, 这与大多数实际情况不符, 如何建立高效的混合缓存策略是目前需要研究的问题。
合作式缓存作为提高缓存系统扩展性的一个方案得到了广泛关注, 设计一个流媒体对象在合作式缓存系统中进行高效分布和缓存的方案, 对提高流媒体缓存技术的扩展性具有重要意义。
参考文献
[1]向广利, 朱平.代理缓存技术在流媒体中的应用.湖北教育学院学报.2005 (5) 26-29
[2]张祥德, 刘兵, 高飞等.流媒体技术研究.计算机应用研究.2003, No.3:82-84.
[3]王国英.Rough集理论与知识获取.西安:西安交通大学出版社.2001:167-203.
[4]周永来.流媒体技术及其在网络广播中的应用:[硕士学位论文].天津:天津大学, 2004.
[5]S.Jin, A.Bestavros, A.Iyenger.Accelerating InternetStreaming Media Delivery Using Network-awarePartial Caching.in:Proceedings of IEEE InternationalConference on Distributed Computing Systems.Vi-enna, Austria.2002.New York, NY, USA:IEEE, 2002.p153-160
[6].罗万明, 林闯, 阎保平.TCP/工P拥塞控制研究.计算机学报.2001 (24一1) .1一1S
[7].吴清亮, 陶军, 刘业.无线多媒体网络中自适应拥塞控制算法的研究.通信学报.2006 (27一12) .48一54
流媒体服务器 篇2
1 引言
随着互联网的飞速发展,流媒体技术的应用越来越广泛,从网上广播、电影播放到远程教学以及在线的新闻网站等都用到了流媒体技术。但现有公开文献所报道的大多是利用现有的流媒体服务器来搭建一个流媒体服务系统，或者是针对流媒体数据的编码方式所进行的研究。本文对流媒体服务器技术的研究重点在于如何建立一个服务器，并且在实现流媒体传输的两个基本协议RTP/RTCP的基础上构建一个基本的流媒体服务器。
2 流媒体技术简介
2.1 “流”的定义
现在网上传输视频、音频主要有下载(Download)和流式传输(Streaming)两种方式。流式传输是连续传送视/音频信号，当流媒体在客户机播放时其余部分在后台继续下载。流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差,以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。
在Inte.net中使用流式传输技术的连续时基媒体就称为流媒体，通常也将其视频与音频称为视频流和音频流。实现流式传输一般都需要专用服务器和播放器。
2.2 流媒体系统组件
流媒体是由各种不同软件构成的，这些软件在各个不同层面上互相通信，基本的流媒体系统包含以下3个组件：
播放器(Player)，用来播放流媒体的软件。
服务器(Server)，用来向用户发送流媒体的软件。
编码器(Encode)，用来将原始的音频视频转化为流媒体格式的软件。
这些组件之间通过特定的协议互相通信，按照特定的格式互相交换文件数据。有些文件中包含了由特定编解码器解码的数据，这种编解码器通过特定算法压缩文件的数据量。
3 流媒体服务器的基本功能和服务方式
3.1 流媒体服务器的主要功能
(1)响应客户的请求，把媒体数据传送给客户。流媒体服务器在流媒体传送期间必须与客户的播放器保持双向通信(这种通信是必需的，因为客户可能随时暂停或快放一个文件)。
(2)响应广播的同时能够及时处理新接收的实时广播数据，并将其编码。
(3)可提供其他额外功能，如：数字权限管理(DRM)，插播广告，分割或镜像其他服务器的流，还有组播。
3.2 流媒体服务器的服务方式
(1)单播。在客户端与媒体服务器之间建立一个单独的数据通道，从1台服务器送出的每个数据包只能传送给1个客户机。
(2)组播。在以组播技术构建的网络上，允许路由器一次将数据包复制到多个通道上。
(3)点播与广播。点播连接是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初始化客户端连接，用户可以开始、停止、后退、快进或暂停流。广播指的是用户被动地接收流，在广播过程中，数据包的单独一个拷贝将发送给网络上的所有用户，客户端接收流，但不能控制流。
4 构建流媒体服务器
4.1 RTP/RTCP协议简介
实时传输协议RTP(Realtime Transport Protocol)：是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。
实时传输控制协议RTCP(Realtime Transport Control Protocol)：负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。
RTCP主要有4个功能:
(1)用反馈信息的方法来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来监视网络和用来诊断网络中的问题;
(2)为RTP源提供一个永久性的CNAME(规范性名字)的传送层标志，因为在发现冲突或者程序更新重启时SSRC(同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得到相联系的数据流(如音频和视频);
(3)根据与会者的数量来调整RTCP包的发送率;
(4)传送会话控制信息，如可在用户接口显示与会者的标识，这是可选功能。
4.2 RTP/RTCP工作过程
工作时，RTP协议从上层接收流媒体信息码流(如H.263)，装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中， RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。
4.3 服务器的算法
服务器软件模型主要有两种，即并发服务器和循环服务器。循环服务器(Iterative Server)是指在一个时刻只处理一个请求的服务器。并发服务器(Concurrent Server)是指在一个时刻可以处理多个请求的服务器。事实上，多数服务器没有用于同时处理多个请求的冗余设备，而是提供一种表面上的并发性，方法是依靠执行多个线程，每个线程处理一个请求，从客户的角度看，服务器就像在并发地与多个客户通信，
电脑资料
由于流媒体服务时间的不定性和数据交互实时性的请求，流媒体服务器一般采用并发服务器算法。本文构建了一个基本的流媒体服务器，能够同时响应多个用户的请求，把本地硬盘流媒体文件或实时数据流(H.263格式)发送给用户。在应用中，把客户分为请求实时数据的实时客户和请求文件数据的文件客户两类。主要算法为：
(1)打开设备，分配资源。当设备准备好时，创建一个RTP实时服务线程和一个RTCP实时服务线程。
(2)创建一个UDP套接字并将其绑定到所提供服务的地址之上。
(3)反复调用接收模块，接收来自客户的RTCP报告，根据其类型做出响应。对新实时客户的请求，把客户地址添加到实时服务的客户列表中，对新文件客户的请求，则创建一个新RTP文件服务线程和一个新RTCP文件服务线程;对已经在服务中的客户则根据RTCP报告的内容调整服务。
RTP实时服务线程1：初始化客户列表和RTP首部。
RTP实时服务线程2：从设备读取媒体数据，把数据发送给实时服务列表中的客户。
RTP实时服务线程3：更新RTP首部和统计数据。
RTP实时服务线程4：计算延时，重复第二步。
RTCP实时服务线程1：初始化RTCP首部。
RTCP实时服务线程2：发送发送方报告给实时服务列表中的客户。
RTCP实时服务线程3：计算延时，重复第二步。
RTP文件服务线程1：初始化RTP首部。
RTP文件服务线程2.：从文件读取媒体数据，把数据发送给客户。
RTP文件服务线程3：更新已发送数据的统计信息，为生成发送方报告做准备。
RTP文件服务线程4：计算延时，调整发送速度，正常情况下开始重复第二步。
RTCP文件服务线程1：初始化RTCP首部，发送一个源描述(SDES)报文给客户。
RTCP文件服务线程2：根据已发送数据的统计信息生成发送方报告，发送给客户。
RTCP文件服务线程3：计算延时，正常情况下开始重复第一步。
5 流媒体服务器实现中应注意的问题
5.1 会话和流的两级分用
一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个 RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识 (SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放。
5.2 多线程的管理
并发服务器模式要求用多线程来提供服务，所以多线程的管理十分重要。在本文构建的服务器中，不同客户的请求和反馈都由服务器的主线程处理，由于实时数据的独有性，不同实时客户可以共用一个RTP实时服务线程和一个RTCP实时服务线程，这样可以大大减小服务器的负担，而每个文件客户由于请求的文件不同，相应地对速度和开始时间的要求都可能不同，所以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。
RTP服务线程负责把实时数据流发送给客户， RTCP服务线程根据RTP线程的统计数据，产生发送方报告给客户。RTP线程和RTCP线程之间通过一段共享内存交互统计数据，对共享内存必须设置互斥体进行保护，防止出现错误读写。在这种方式下，服务器可以根据每个用户的不同请求和具体情况方便地提供不同的服务。
5.3 时间戳的处理
时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间 (Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。
RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。
在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。
5.4 媒体数据发送速度的控制
由于RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为例，由于文件本身不包含帧率信息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧率和预置值来计算时延，以适当的速度发送数据并设置时间戳信息。
5.5 多种流同步
RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name)，尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。
6 结论
流媒体技术的应用日益广泛，对流媒体技术的研究具有很大的实际意义,本文通过对RTP/RTCP协议的研究，分析流媒体服务器的一般功能和结构，给出构建一个基本的流媒体服务器的实现方案，实验证明可以同时满足多个实时和文件客户的要求,并已经应用于一个远程监控系统中。
流媒体音乐服务，谁在赚钱 篇3
虽然流媒体音乐服务霎时间因为科技巨头的加入而被炒到了风口浪尖，但实际上这个领域很难实现盈利，以该领域的领先企业Pandora和Spotify为例，尽管它们吸引了数亿美元的融资和数千万的用户，但至今几乎未实现盈利。
Pandora于2011年上市，目前每月全球用户高达6700万，音乐收听的总时长超过130亿小时。其通过在线广播服务随机播放歌曲并收取广告费用来支付版权费，在2012年，亏损达3810万美元。总部在瑞典的Spotify于2011年登陆美国，仅在不到一个月的时间成功获得了 140 万用户，其中包括约18万的付费用户，付费转换率为12.5%，其目前在全球拥有2400万活跃用户，其中付费用户600万。用户每个月只需要支付 9.99 美元就可以随时随地享受Spotify音乐库中所有的歌曲，但即便Spotify的免费服务达到了如此之高的转化率，其终究也没怎么赚到钱。光鲜靓丽的用户疯涨背后是节节攀升的亏损，其在2011年，Spotify的营收为2.44亿美元，但亏损达6000万美元。
此类流媒体音乐公司亏损的主要原因是流媒体播放歌曲要支付高昂的版权费，一般是按播放次数支付，一个订户每月付费中的70%用于支付版权。再加上持续上涨的销售和营销成本，都使得盈利变得遥遥无期。
目前，Apple和Google这类的大公司都在抢着进入这个赔本的市场，究竟是为了什么？一个词：生态圈。无论Apple还是Google，这些巨头对移动领域的重视是众所周知的，它们很少会因为音乐流本身的价值所以去投资，而更重要的是考虑到其旗下其他设备和服务的销售。自苹果推出iTunes在线音乐商店，这种颠覆时代的音乐销售模式已经使音乐融入到移动体验中。音乐服务早已成为移动设备应用中最重要组成部分之一，如果在此领域失利的话，将来的其他业务也将面临拱手让人的危险。根据市场研究公司ComScore今年发布的移动设备调查显示，48%的智能手机用户会利用他们的设备听音乐，如果将购买智能手机的考虑因素按1分至10分排列，其中10分为最重要的因素，手机音乐和视频播放功能的得分为7.41分。
这样的危机感使得科技巨头迫不及待地在流媒体音乐服务领域显示它们的市场力量，尤其是拥有庞大在线音乐用户群的苹果不可能轻易地将音乐市场头把交椅的位置出让。事实上，对于这些科技大腕级公司来说，即使流媒体音乐无法实现盈利，它们也可以通过完善生态系统的方式来提高硬件的销售量，以此来平衡损失。
许多时候，做生意的第一步都是“赔本赚吆喝”。要知道，纵使Pandora在赔钱，依靠其千万级的用户量，它依旧是仅次于Google和Facebook的第三大移动广告销售商，其每年移动广告销售额超过1亿美元，而且该公司营收主要是依靠广告。Spotify也意识到了这点，它在继续提高付费用户转化率的同时，也在努力扩大来自广告的收入。2009 年 Spotify 的广告收入还是 712 万美元，到 2010 年这一数字飙升到了 2853 万美元。
由于广告收入的翻倍疯涨，即使运营成本和收入呈现同步上涨的趋势，流媒体音乐公司从每位用户身上获得的净利润也会增加。当广告营收的增长速度超过运营支出的增长速度，此类公司便可达到健康的长期发展。因而这种广告加用户订阅的商业模式能否胜出，取决于公司是否能有效地卖出广告。眼下，流媒体音乐市场进入了很多大玩家，Apple希望通过iRadio加强其移动广告服务平台iAds，并且凭借更加相关的用户数据来扩展iAds平台。
与巨头们提供的音乐下载、音乐点播以及云存储等服务相比，Spotify这类公司的服务形式过于单一，此外，巨头们的音乐库中的歌曲数量都在Spotify之上，他们的流媒体服务与旗下其他产品的整合，将对小公司未来的市场扩展造成冲击。不过，大公司很少为了从事一个非主流的服务而千万百计地去寻找新的业务模式，即使巨头进入市场，Spotify这样的公司依旧有灵活的生存空间。
流媒体服务器 篇4
Internet是一个"尽力而为"的网络环境,它对实时多媒体应用缺乏足够的服务质量(QoS)保证,不能为实时流媒体的网络传输提供稳定的带宽和低延时的网络环境[1,2,3]。随着多媒体通信量的激增,流媒体服务质量就会降低,会发生多媒体数据包的延迟和丢失,进而导致视频播放时出现花屏、马赛克和停顿,音频不连续,音频和视频不同步等现象。流媒体服务器是视频直播系统的核心,流媒体服务器应该对网络环境具有自适应性,使之能提供具有一定QoS保证的流媒体服务。
本文给出的流媒体服务器QoS保证措施是根据接收端反馈的网络变化情况以及服务器资源情况自动调整服务策略。这些措施已经在实际视频直播平台上得以实现,为视频流的接收提供了最大限度的服务质量。
1流媒体服务器质量保证功能的设计
本系统主要是通过五个软件模块的功能来保证直播流媒体服务器的服务质量。这些模块包括:重叠IO通信模块、连接控制模块、多线程转发模块、速率控制模块和差错控制模块,使直播流媒体服务器系统能作为一个有机整体完成多路音视频的转发、调度工作,提供服务质量保证。
1.1重叠IO通信模块
Winsock为基于网络的应用程序提出了五种I/O模型[4],包括select单线程的选择模型、WSAAsynSelect基于消息窗口异步选择模型、WSAEventSelect基于事件的选择模型、OverlappedI/O重叠I/O以及CompletionPort完成端口。这五种模型应用于套接字的异步通信接口,五种I/O模型都有各自的优点和缺点,根据具体的应用环境选择适当的I/O模型。
在视频直播环境下,同一段时间内不是所有的人员同时发言,大部分人员都是会议的旁听者,所以视频服务器在同一段时间内只需要转发一部分人员的视频和音频数据,但所有与会人员都必须接收发言者的音视频数据。影响该模块设计的关键因素就是要满足至少5000个客户端的同时连接请求,关系到整个服务器系统的稳定性和健壮性。为此,本系统采用Win32的基于事件的重叠I/O端口来完成底层的音视频数据流的传输和上层应用线程同时多项I/O请求,而重叠的I/O操作由重叠套接字在后台完成,且同一时间请求I/O操作的各应用线程可继续去做其它的事情,不必等待。
在一个套接字上进行重叠I/O操作的基本算法如下:
(1) 创建套接字
(2) 绑定IP及端口
(3) 套接字接收消息
1.2连接控制模块
连接控制模块主要是完成用户进入、退出和异常终止视频直播系统等控制功能。为了保证服务器质量,根据服务器性能预先设置若干个转发模块,当转发模块用完时,系统将控制在线用户新的发言请求,该用户只能旁听。连接控制模块主要算法如下:
(1) 进入会议室获得当前会议状态
(2) 退出会议室删除当前用户
INT CVConSrv_ConRoom::DelMemInfo(SOCKET Socket,SHORT shortID)
(3) 在线用户申请发言
(4) 在线用户停止发言函数
1.3多线程转发模块
在服务器系统启动时,初始化线程创建一定数量的转发模块,每个转发模块以线程的方式运行,在空闲的时候处于“挂起”的状态。转发模块的底层是采用重叠IO端口的工作方式,故它可对多个IO端口进行统一管理。每个转发模块都定义了两个重叠套接字DataSocket和CommandSocket,且这两个套接字分别邦定工作线程DataThreadFunct和CommandThreadFunc。DataThreadFunc工作线程负责监听并处理DataSocket套接字上的连接请求,即负责接收会议室中发言用户的音视频数据流。CommandThreadFunc工作线程负责监听并处理CommandSocket套按字上的所有连接请求。当用户向转发模块申请数据时,工作线程CommandThreadFunc将用户的信息保存在“转发列表”中,以便DataThreadFunc线程向该用户转发数据。线程CommandthreadFunc向新用户发送音视频的媒体类型数据,初始化接收端的解码器。多线程转发模块算法如下:
(1) 转发启动函数
(2) 数据线程函数
(3) 命令线程函数
1.4速率控制模块
在文献[4]中视频流通过TCP传输,视频传输质量是通过减少TCP的连接会话数量来保证,通过NS2仿真实现。文献[5]为了保证接收端的视频质量,通过调整服务器发送端的配置参数实现,需要预先知道视频文件的资源需求,设置若干个配置描述存储在服务器上,不同的配置之间的实时转换需要消耗更多时间,并且仅在实验室内进行了模拟研究,不适合本系统实时流媒体的分发。以本文是根据接收端反馈的信息(包括接收的累积数据包总数、丢失的数据包数、往返延迟、抖动等),估算网络可用带宽,再结合可扩展编解器XVID的编码方式[6],采用平滑算法来控制数据包的发送率,在实际大规模网络视频互动平台上得以实现,并已经投入运营。
本文采用的可扩展编解码器XVID的编码方式,是将多媒体数据分成基本层和增强层。基本层是对源数据的最大压缩比编码,若没有基本层则整个数据帧就无法解码和播放。增强层必须和基本层一块使用,增强层越多播放质量就会越好。在这种可扩展编码方式的支持下,由于将视频的基本数据和表现细节的数据分别置于不同的层中,服务器可以动态地根据网络状况来决定传输多少细节数据,以动态调整数据传输速率,发送率的调整采用慢速增加快速递减的策略。定义丢包率γ=(1-λ)× γ0+λγ1 。其中λ为平滑因子,若其值越大则说明越重视当前的网络状况,反之越重视以前的网络状况,本系统λ取值为0.75～0.9。γ0为上一次采用平滑算法得到的丢包率,γ1为当前接收到的丢包率,γ为本次估计的丢包率。
速率控制模块的算法如下:
1.5差错控制模块
本系统采用UDP作为传输层协议来传输视频流数据,但UDP没有提供差错控制机制,不能保证接收到的视频质量。本服务器系统针对MPEG4视频编码的特点,文献[7,8]的差错控制方法,,增加了差错控制模块。
本系统在服务器的应用层设计视频数据包结构,包括数据包长度、帧序号、帧内包序号、帧内包总数、帧类型、时间戳和有效载荷。利用包头信息和接收端缓冲区完成差错控制。
在接收端设置了二级缓冲机制,接收线程将数据包按其时间戳和帧内序列号的递增顺序插入到一级缓冲区中。然后将最近要播放帧的数据包缓存到二级缓冲区中,接收端的解码器仅从二级缓冲区中读取数据播放。
若视频流以25帧/秒的速率播放,则平均每帧数据的播放时间约为40ms,而大小为1 kbit/s的数据包在300 kbit/s的可用网络带宽上的传输延时约为2ms,所以本系统在接收端的二极缓冲区缓存三帧数据即可。本系统只对关键帧中出现差错的数据进行重传,且只重传一次。
(1) 客户端差错控制算法
(2) 服务器端重传差错控制算法
2系统测试
为了测试本系统可达到合同规定的5000人同时在线的要求,提高服务器系统性能,我们采用了一种基于Windows完成端口(IOCP)的测试模型, 设计了一个客户请求和视频发送、接收仿真器[9],在单台服务器上模拟了大量用户流量,对本服务器系统进行了性能测试,测试结果表明并发用户数与服务器的网络带宽及CPU的关系如图1和2所示。测试环境是用一台服务器是普通PC级服务器,四核3.0主频,内存8GB,网络带宽1000M。
当服务器中一个转发模块的并发人数不超过500人时,各个接收端的视频非常流畅、声音非常连续、视频和音频间也非常同步;当服务器的一个转发模块的并发人数超过500人时,有些接收端的视频偶尔出现停顿、不连续的现象,但所有接收端的音频非常连续,音频和视频间的同步也正常;当服务器的一个转发模块的并发人数超过1000人时,大部分接收端的视频效果很差,出现长时间的停顿现象,声音也断断续续,音视频音的同步也不正常。
在测试中发现并发用户数的增加对服务器的内存几乎没有影响,服务器占用内存一般不会超过20MB。这是因为服务器绝大多数情况下只起着数据转发作用,很少需要缓存数据。即使服务器需要缓存数据,一般情况下也只缓存一个新加入会议的与会者信息,而该信息数据量非常小。
由于服务器每个转发模块可处理的并发用户数在150人以内,所以为了满足5000人同时在线,需要一个控制服务器,创建和控制转发模块,10个转发服务器,每个服务器上1个转发模块,共用了11台服务器作为视频转发服务器集群。如果要求更大数量的人数开会,可以采用服务器集群技术来扩大服务器的数量,同时多个服务器可以设置在不同的物理位置,从而构建网状的支撑音视频的分布式应用平台。
3结语
本文分析流媒体服务器的功能和结构,并设计实现了具有5种QoS措施的流媒体服务器。该服务器系统能根据动态变化的网络带宽情况和客户端的异构情况平滑地调整服务器的转发速率。通过测试确定了某个省级联通用户同时在线5000个用户需求的软硬件配置方案作为运营环境,即本系统的应用环境。该服务器系统已经很好地在省级联通视频直播平台上运行两年多,并得到客户较好的评价。
应用环境是运营级千兆Internet网络出口及5台级联服务器,即由1台主服务器接收发言者的音视频数据然后将此数据转发至其它四台转发服务器上,再由转发服务器传送给最终客户端,主服务器与转发服务器之间是局域网百兆连接,保证数据的及时性。在运营环境下音视频数据实现了较好的同步,延迟能保证在一秒之内,属于用户可接受的范围内。
参考文献
[1]Zhang S Q,Zhao B Y.Bayeux:An Architecture for Scalable and FaultTolerant Wide Area Data Dissemination[C]//Proceeding of 11thWorkshop Network and Operating System Support for Digital Audio andVideo.New York,USA,2001:11-20.
[2]王艳丽,鲜继清,白洁.基于P2P的流媒体技术[J].计算机应用,2007,25(6):1267-1270.
[3]李争明,张佐.直播服务器一般性框架体系设计[J].计算机应用,2005,25(2):1-3.
[4]Nomoto Y,Hayashi K,Ishibashi Y.Video server system using IP storagein long-delay network[C]//Consumer Electronics ISCE'09.Braun-schweig,Germany,2009:866-870.
[5]Hang Yu,Ee Chien Chang,Wei Tsang Ooi,et al.Integrated Optimiza-tion of Video Server Resource and Streaming Quality Over Best-EffortNetwork[J].IEEE Circuits and Systems for Video Technology,2009,19(3):374-385.
[6]龙国泉.视频会议系统中关键技术研究[D].沈阳:东北大学,2008-01-15.
[7]Caij,Zhang Q,Zhe W.An FEC-based error control scheme for wirelessMPEG-4 video transmission[C]//Wireless Communications and Net-working Conference.Chicago,USA,2000,3(3):1243-1247.
[8]Yamaguchim I,Takasakiy K.Packet loss detection scheme for retrans-mission-based real-time data transfer[C]//7th International Conferenceon Parallel and Distributed Systems.Iwate,Japan,2000:49-54.
新媒体推广服务合同 篇5
【当事人情况】 甲方： 地址： 法定代表人： 电话： 联系人： 电子邮件： 乙方： 地址： 法定代表人： 电话： 联系人： 电子邮件
第一条 目的描述
1、根据中华人民共和国相关法律、法规，经甲乙双方协商达成共识，双方申明：双方都已理解并认可了本协议的所有内容，同意承担各自应承担的权利和义务，忠实地履行本协议。
第二条 推广内容
1、甲方为乙方战略合作伙伴。在合作期间，享有通过乙方的信息服务、广告推广等方式提升品牌形象和社会影响力的优先权。
第三条 推广时间
1、本合同服务期限自【 】年【 】月【 】日至【 】年【 】月【 】日止。
第四条 推广方式
1、乙方充分利用其网络媒体资源，通过网络链接、信息发布等方式为甲方提供宣传推广服务，以提升甲方的形象和影响。
第五条 推广载体
1、甲方选择所要投放的搜索引擎为【 】。
第六条 计价标准
1、本合同费用为人民币（大写）【 】（￥ 【 】元）。本次合同内容为下列第【 】项。
（1）网络广告：折后总金额【 】元整，刊例价以2011年刊例执行，在资源发生变动的情况下，乙方确保以同等价值资源替换原来资源。
（2）专题制作发布：乙方在为甲方提供首页网络广告位的同时，为其量身设计制作形式精美、内容丰富的宣传专题，对甲方的发展战略及各个时期的中心工作、成就等以图文并茂的形式进行全方位展示推广。甲方负责提供专题素材。乙方负责对该专题进行维护，及时汇集涉及甲方的各类媒体报道并更新。（3）舆情信息服务：乙方协助甲方开展网络舆情监测，为甲方提供舆情应对建议方案并协助实施。由此产生的额外费用由双方另行约定。
（4）线下活动策划：乙方可参与甲方宣传推广及重大活动的策划，以更好地提升甲方的形象和社会影响。由此产生的额外费用由双方另行约定。
（5）其他宣传推广服务。
第七条 合同金额
1、合同推广服务费总金额为人民币【 】整（￥【 】元）。前述费用已包含乙方按本合同约定履行发生的全部费用，包括但不限于推广、技术支持、平台维护、管理、沟通联系、税金等一切费用。除上述费用外，甲方无需支付其他任何费用。
第八条 结算条件
1、甲方在合同签订并收到乙方此次合同发票后【 】个工作日内向乙方支付此次合同款项。
第九条 支付方式
1、甲方向乙方以支票或汇款方式支付到：
开户名称：【 】
开户银行：【 】
账号：【 】 第十条 内容提供及确认
1、甲方至少在广告开始刊登前15个工作日提供广告或专题素材（文字链标题、图片、文章、影片等）。乙方不承担因甲方延迟提供素材而导致的广告刊发（或专题发布）延迟的责任。
第十一条 内容变更
1、（1）乙方未经甲方许可不得擅自更改甲方网上信息推广的内容、形式、位置和时间。
（2）乙方制作或修改的相关内容在发布前须获甲方书面同意。
第十二条 运营与保障
1、合同期内，乙方负责推广平台的维护，确保推广品牌及信息按约定持续、有效、完整、准确发布。若推广中断，乙方应及时处理恢复，相关费用由乙方自行承担。若推广内容被删除，或推广内容中断持续达12小时。
第十三条 其他
1、（1）乙方应以电话、传真以及电子邮件提供推广结果。
（2）推广结果达到约定效果即为验收合格。
（3）甲方应及时验收确认。
（4）验收期限为三天，如果甲方超过验收期未验收乙方将视为验收满意。
（5）甲方完成验收后以合同提供的联系方式及时联系乙方。第十四条 监督权
1、甲方有权要求乙方遵照合同的约定完成推广服务，有权对实际推广情况进行监督、核实，并以书面方式提出异议及修改意见。
第十五条 内容合规义务
1、甲方提交的素材必须客观真实、符合国家相关法规和广告法的管理法规，不得伤害消费者利益。乙方不负责由甲方提供的素材内容所造成的任何损失。
第十六条 付费义务
1、甲方应按照合同的约定，及时支付费用。
第十七条 收费权
1、乙方有权就其向甲方提供的推广服务向甲方收取约定的费用。
第十八条 内容审查权
1、乙方有权审查推广内容和表现形式，对不符合法律、法规的广告内容和表现形式，乙方有权要求甲方作出相应修改，甲方作出修改前，乙方有权推迟或拒绝推送。推送后因内容和表现形式不符合法律、法规的要求而导致的经济法律责任由乙方承担。
第十九条 尽责推广义务
1、乙方应按约定提供推广服务。
第二十条 手续办理义务
1、甲方应向乙方提供推广信息所必须的文件和有效证明，乙方负责推广内容的制作发布并办理推送本信息所涉及到的各类审批登记备案手续，取得相应的批准文号，并承担相应费用。若因手续不完备造成的一切损失及处罚由乙方承担。
第二十一条 媒体维护义务
1、乙方协助甲方开展网络舆情监测并提供应对方案，由此产生的额外费用由甲方承担。
第二十二条 保密内容
1、任何一方对在本合同履行过程中，均对对方的商业秘密或其他技术、经营信息负有相应的保密义务，双方均不得向任何其他第三方泄露相关机密、技术和信息，但中国现行法律、法规另有规定或经另一方书面同意的除外。
第二十三条 保密责任
1、任何一方故意泄露对方商业秘密而造成守约方损失的，违约方须赔偿守约方因此遭受的全部损失，包括但不限于为主张权利而产生的律师费、诉讼费等一切费用。
第二十四条 知识产权1、1、双方保证一方向另一方提供的资料不会侵犯任何其他人的知识产权或合法权益，否则一切责任由该方自行承担，概与另一方无关。
2、双方保证一方根据本合同获知或获准使用的另一方的硬件、软件、程序、密码、商品名、技术、许可证、专利、商标、技术知识和经营过程是另一方的合法所有，该方对此无任何权利或利益。
第二十五条 一般条款1、1、乙方在签订本合同后，如证实无法向甲方提供规定的服务，甲方有权与乙方中止合同。
2、任何一方有证据表明对方已经、正在或将要违约，可以提出中止履行本合同，但应及时通知对方。
第二十六条 解除条款
1、（1）除非本合同另有规定，一方严重违反本合同规定的任何条件且在另一方向其提出书面通知后15天内没有改正的，另一方有权终止本合同，本合同自该有权终止方发出终止通知之日起解除。
（2）一方进入破产申请或清算程序，另一方有权终止本合同，本合同自该有权终止方发出通知日起解除。
第二十七条 不可抗力
1、合同履行期间，如因政府政策或其它法定不可抗力因素致使当事人一方不能履行合同的，应向对方当事人通报理由，双方互不负违约责任，并允许协商变更或解除合同。如解除合同的，乙方应退还甲方已向乙方预付而未使用的服务费用。
第二十八条 特殊免责条款
1、如因搜索引擎平台对其服务内容、版面布局、页面设计等进行调整而影响广告计划的执行，乙方不承担责任，但应由乙方同相关搜索引擎平台进行协商，调整发布计划，并报甲方确认后执行。
第二十九条 合同生效与变更
1、本合同自双方签字、盖章之日起生效。
第三十条 合同期限
1、本合同有效期为【 】日至【 】日。在合同到期后，甲方保留优先合作权。
第三十一条 合同终止
1、本合同在下述情形下自动终止，双方互不负责，但终止方应提前7个工作日以书面的形式通知另一方，广告费用按实际投放天数计算：
（1）当事人主体资格消失，如破产。但进行重组、名称变更或者与第三方合并等不在此列；
（2）因不可抗力而解除本合同或者双方当事人协商一致解除本合同的；
（3）其它依法律、法规规定的情形而不得不终止合同。
第三十二条 复数文件和语言
1、（1）本合同壹式贰份，甲方执壹份，乙方执壹份，具有同等法律效力。
（2）本合同未尽事宜，双方另行协商后签订补充协议，补充协议于本合同具有同等法律效力。
第三十三条 法律适用
1、本合同的订立、履行、解释及争议的解决均适用中华人民共和国法律。
第三十四条 纠纷解决程序与管辖
1、因履行本合同所产生的或者与本合同有关的争议，甲乙双方应友好协商解决，协商不成的，双方一致同意将该争议提交【 】仲裁委员会仲裁。
第三十五条 通知与送达
1、甲乙双方之间的有效通讯联系地址以本合同列明的为准。如有变更，应及时书面通知对方。如变更后未及时书面通知对方，则视为未变更。双方之间与本合同有关的文件除直接送达外，应以挂号信函或中国邮政特快专递的方式进行。一经送达上述联系方式，即视为送达。
第三十六条 合同清理条款
1、保密条款为永久性生效条款，不因合同的中止而失效。第三十七条 其他条款
1、本合同乃为双方及其各自之合法继任者之利益而制定，并对双方及其各自之合法继任者具有同等约束力。任何一方发生合并、分立、解散均不影响本合同的继续履行。任何一方如需将权利或义务转让或以其他方式让与给他人，需获得另一方同意，并签署三方协议。
第三十八条 授权委托
1、本合同经各方授权代表于【 日签署于中国【 】。
【签署条款】
甲方： 盖章： 授权代表签字： 日期： 】月【乙方： 盖章：
授权代表签字： 日期：
媒体更需要卖服务 篇6
美国博斯公司全球合伙人，常驻上海。毕业于上海复旦大学新闻学院，并持有英国曼彻斯特大学商学院MBA证书。
拥有超过10年管理咨询经验，在城市、区域总体规划和专项规划、品牌营销、服务外包、国企改革、媒体战略等方面形成了系统的方法论和独到的见解
奥运会不光是体育的盛宴，也是媒体的盛宴。资金雄厚的厂商们在电视、杂志、报纸、网络多管齐下，衬托着全民奥运的热闹气氛。2008年以来的全球经济动荡，导致媒体尤其是传统媒体行业陷入了前所未有的低谷。虽然这个行业的许多公司在经济衰退前就已经着手进行业务的重大转型，但传统媒体的受众数量受到经济衰退的影响依然在缩水，而数字媒体收益的增长速度却还不足以填补缺口。
在当前业务模式以及未来增长前景都极不确定的情况下，各大媒体公司正在努力寻找合适的战略举措，迎接传统媒体向数字媒体转变所带来的巨大挑战，获取新的增长机会。可以肯定的是，媒体行业的未来趋势之一是，由企业、代理商、媒体公司构成的传统价值链将继续演变、拆分、重组，变得更为多样化。
争夺广告份额的竞争愈演愈烈，企业将越来越多的市场营销资金流向了数字媒体，该领域的传统报告条线已经模糊。品类领先的大型媒体公司正在制定“媒体服务”战略，这有利于发展与主要客户的直接关系并扩大市场营销方案的范围。例如，梅雷迪斯（Meredith）、ESPN、MTV、NBC环球、美国国际数据集团（IDG）等媒体公司都在努力为关键客户提供更多咨询服务和解决方案。
以美国的梅雷迪斯公司为例。从1902年出版Successful Farming杂志创立至今，梅雷迪斯公司旗下仅杂志媒体就包括了21份订阅杂志以及150份零售杂志。而在梅雷迪斯公司的网站上，它自定义为一家领先的媒体及营销公司，由此可见梅雷迪斯已经开始从传统媒体向多元化公司进行转型。
除了以杂志、电视和网络媒体为根基外，梅雷迪斯公司还积极拓展了营销公司的角色，为美国很多顶级的品牌和公司定制市场营销解决方案。梅雷迪斯公司的市场营销部门在2011年重组为Meredith Xcelerated Marketing公司，近年来收购了多家数字、社交、医疗、数据库和国际营销方面的领先公司。如果说现在的梅雷迪斯公司是一家首屈一指的营销公司，想必也不会有所异议，因为在该公司旗下包括了进行口碑营销的NMS公司，数据库营销的Directive公司，在线及移动营销的O'Grady Meyers和The Hyperfactory公司，定制化医疗营销的BIG公司等。
梅雷迪斯公司的例子告诉我们，在今后，媒体服务的趋势将更为明显，原因有几点。多数企业都希望开展横跨多个平台的营销活动，突出数字媒体，深入洞察消费者需求。同时，媒体公司需要进一步促进传统媒体以及数字媒体的广告相关增长。博斯公司从与美国全国广告商协会、美国互动广告局、美国广告代理商协会联合开展的一项研究《2010年市场营销与媒体生态系统》中发现，媒体公司将最终培养品类管理能力，以便与企业开展密切协作。消费品领域也有类似的举措，许多生产包装消费品的企业会建立零售团队与沃尔玛、Target等零售机构开展紧密合作。预计未来很多领先的媒体公司都会加强对“销售+服务”结构的关注。
同时，大型企业将继续发展自身的媒体资产，尤其是在数字媒体领域，包括大众、耐克、通用磨坊、强生、宝洁、惠普等世界知名品牌。这一发展趋势具有一定的破坏性，对长期以广告为中心的商业模式形成挑战。企业自身创建的媒体越多，它们会购买的媒体资源就越少。卡夫食品（2009年的付费媒体开支约为8亿美元）等大型广告商正计划扩大自营杂志及数字媒体的发行力度，因为这些媒体的吸引力关乎客户资源获取以及激活，媒体公司需要对此加以重视。
流媒体服务器 篇7
1 流媒体负载均衡的原理
流媒体负载均衡是对分散的多个流媒体服务器进行集中管理的技术手段。流媒体负载均衡按一定的条件将流媒体服务器划分成组,组中每台服务器可以是对等的,也可以是分级的,但是都可以单独对外提供服务而无需其他服务器的辅助。
负载均衡设备对集群服务器进行健康检测(性能检测),确保集群中每台服务器都能单独接受用户请求,否则将其退出集群;然后按照一定的均衡算法,将流媒体请求定向到指定的服务器上,受分配的服务器独立地回应客户的请求[2]。
在实际使用中,用户只需记住1台服务器,即虚拟服务器,但其数据流能够被负载均衡器灵活地均衡到所有的服务。流媒体负载均衡实现原理图如图1所示。
由此可见,基于流媒体负载均衡技术的服务器集群平台至少可以实现以下两个功能:①运行功能,通过负载均衡可以集群多个流媒体服务器共同完成众多流媒体服务请求;②维护功能,通过健康检测可以对多个流媒体服务器进行集中监控和维护。
2 硬件实现的设备连接方式
负载均衡可以通过软件实现,也可以通过硬件实现。软件实现是指在服务器的操作系统上安装应用程序来实现负载均衡;硬件实现是指在服务器和互联网间安装负载均衡设备。硬件实现相比软件实现整体性能得到大幅提高,加上多样化的负载均衡策略,智能化的流量管理,可达到最佳的负载均衡需求。采用硬件方式实现的流媒体负载均衡,实施前需确定负载均衡设备连接方式。经调研,负载均衡连接方式主要有直连和旁连两种。
2.1 直连方式
直连方式是指所有流媒体服务器连接到负载均衡设备上,负载均衡设备再连接到交换机上并接入互联网。直连方式的设备连接及其数据流量走向如图2所示。
直连方式中,客户端数据首先经过负载均衡设备,负载均衡设备按均衡算法将数据传达到后台服务器,服务器响应请求并将数据返回给负载均衡设备,负载均衡设备接收到服务器数据后,再将数据传输给客户端。直连方式的数据交互过程如图3所示。
从以上分析可以看出,直连方式的每次数据交互都必须经过负载均衡设备,缺乏灵活性,数据时延较大;且该连接方式存在安全瓶颈,一旦负载均衡设备的网络链路中断,则所有服务器也会随之退出平台。
2.2 旁连方式
旁连方式是指将负载均衡设备及流媒体服务器一同连接到交换机上并接入互联网。旁连方式的设备连接及其数据流量走向如图4所示。
旁连方式中客户端想要接收流媒体服务时,则访问负载均衡器虚拟IP地址。负载均衡器按预先设定的规则进行信息分析,并依据一定的算法确定应该分配给哪一台服务器。然后请求服务的客户端被要求重定向到指定的流媒体服务器,最后客户端绕过负载均衡设备直接与指定的流媒体服务器建立连接,接收流媒体服。整个数据交互过程如图5所示。
根据旁连方式的工作过程,可以得出此连接方式有如下优点。
(1)增加了网络的灵活性。特定条件下如需对指定的某台服务器进行登录管理,只要通过授权获知其IP,即可直接登录,而不受负载均衡的分配。同时,一些特殊的应用,也可在核心交换机上采用策略路由的方式指向特定的网络设备。动静态分配相结合,大大增加了集群平台的灵活性。
(2)提高了网络整体的可靠性。采用旁连方式后,如果负载均衡设备出现问题,访问客户端可通过获知备用IP (流媒体服务器的真实地址)绕过负载均衡设备直接访问流媒体服务器,而不会对整个业务系统造成影响。
(3)提高了网络通信的有效性。旁连方式中,客户端重定向到指定的流媒体服务器后,此后的数据交互不再经过负载均衡设备,大大减短了流媒体数据时延。
(4)施工维护简单。如果对原没有负载均衡技术的系统进行负载均衡技术改造,那么,在直连情况下,服务器的IP地址、网络结构都要作调整(将服务器调到负载均衡后端),同时相关联的应用也要改动,需要进行严格的测试才能上线运行;然而,在旁连模式下,原有系统(包括网络结构)基本不需要作任何改动,故前者对系统改动较大,后者则改动较小。
根据以上各项指标的综合分析,该服务器集群平台采用旁连方式比较合适。
3 健康检测
为了防止客户端被均衡到故障流媒体服务器上,我们需对流媒体服务器的状态进行实时监控,即负载均衡设备模拟客户端向流媒体服务器发送数据请求,若流媒体服务器能够在规定时间实现握手回应,则将其保留在集群中,否则退出;这个过程对所有流媒体服务器是不断轮询地进行的,从而保证对服务器的检测是实时的。
流媒体服务器健康检测流程如图6所示。
由于负载均衡器对流媒体服务器的检测是实时的,且能够显示出当前服务器的性能状况,给设备运维人员提供了有效的监测手段。
4 均衡算法及其实现方法[3,4,5]
负载均衡设备可以提供多种灵活的均衡算法,将数据流有效地转发到它所连接的服务器群。此系统设计中,负载均衡采用轮询+优先权的均衡算法。
4.1 轮询(Round Robin)
轮询(Round Robin)即将请求顺序循环地连接给每个服务器;在轮询算法下,集群中的服务器都是对等的而没有主次之分,服务器被分配到客户请求的事件是等概率的。
轮询算法的优点是实现简单,基本不需要策略设置,且对每台服务器都能实时利用。但是轮询算法不利于对集群中的服务器使用进行规划和掌握。在具体实现中,负载均衡一般避免这种算法;而健康检测往往采用这种算法,对所有服务器循环地进行检测,保证对每台服务器都能实时监控和管理。
4.2 优先权(Priority)
优先权(Priority)即给服务器分组,给每个组定义优先权,流媒体负载均衡设备将用户的请求分配给优先级最高的服务器组;当最高优先级别的组中所有服务器都不能再接受请求时,流媒体负载均衡设备才将请求送给次优先级的服务器组。这种方式实际上是为用户提供一种热备份的方式。
优先权算法的特点是可以通过设定优先级对集群中的服务器使用方案先期进行规划和设计,从而避免了盲目性;故在负载均衡中普遍采用这种算法。
为了实现优先权算法,必须先制定优先权策略,即分级的依据。根据企业通信设备属地化运维和双重化配置的特点,该服务器集群平台中,我们采用属地优先+主用优先的策略。
属地优先指客户请求优先分配给客户端所在地市的服务器组;主用优先指客户请求优先分配给指定的主用服务器。两者相结合,则客户请求会优先分配给客户端所在地市的服务器组中的主用服务器。
为了具体实现属地优先+主用优先的策略,在负载均衡器中对集群里要对所有的流媒体服务器先进行分组分级的配置。分组是将所有流媒体服务器按一定规则分组,具体实现是将同属同一地市公司的流媒体服务器合成一组;分级是进一步将组中的主用流媒体服务器设为高优先级,备用流媒体服务器设为低优先级。分组分级能将所有服务器进行有效整合,防止当某一组合成员无一正常运行时,可及时跳转到优先级相对较低组合成员上,保证客户端都能有效访问服务器。
负载均衡器具体配置中将各地区客户端所分配IP地址范围写入各自命名数据库内,数据库命名规则为各地区拼音首字母,例如江苏省公司用“JS”、南京地市公司用“NJ”,代表了相应的IP地址范围。然后为各组中的流媒体服务器设置优先级标识,主用赋予高优先级标识,备用赋予低优先级标识。
服务启动后,客户端访问集群服务器虚拟地址,负载均衡获取客户端IP地址信息,然后与数据库地址表比较,找到客户端IP所属市公司流媒体服务器组。确定所在分组后,进一步按照优先权的算法挑选优先级最高的流媒体服务器,然后按轮询的方式,顺序循环对组中服务器先健康检测,一旦满足性能要求则选中。若本地的流媒体服务器组都不能接受请求,则进一步将客户端请求依优先级别分配给省公司和其他地市公司的服务器组。
“属地优先”的重要代码如下:
(1)提高了流媒体服务的可靠性。负载均衡将分散的多个流媒体服务器组合成强大的服务器组,可以保证长期不间断地承载大量的服务请求。
(2)提高了流媒体服务的有效性。全省区域的用户在请求流媒体服务时,一般都只需要使用负载均衡虚拟IP地址,即可按均衡方式访问全省的服务器群,增强了访问有效性。
(3)提高了流媒体服务器的可控度。负载均衡提供了对流媒体服务器的监控手段——健康检测,运维人员可依据检测结果判断服务器正常与否,从而为状态检修提供重要依据。
随着电力通信数据网日益扩充,各类新业务不断涌现,通信数据量越来越庞大,对通信资源必须采取恰当合理的调度分配,才能确保通信网各类系统的安全稳定运行。
5 总结与展望
在江苏省电力公司部署一套负载均衡系统,在不对现有广域信息网设备进行改造、调整的情况下,成功实现了全省流媒体服务器负载均衡,节省了设备投资和运维费用。通过负载均衡系统将省、市公司所有流媒体服务器资源进行整合,大大提高了网络直播会议系统的并发用户数,从而为国网公司和省公司各项会议精神能准确、迅速地直接传达到每位电力员工提供了一条方便快捷的通信通道。在近2个月的试运行过程中,员工反映流媒体客户端访问流畅,流媒体服务器运行正常无堵塞,满足了实际调度运行需要。
总结该流媒体服务器集群平台主要有以下几个优点。
参考文献
[1]罗云峰,朱秋萍.流媒体通信技术及其应用[J].中国数据通信,2002,4(6):70-73.
[2]龙著乾.流媒体服务器集群的负载均衡研究[J].软件,2013,34(4):62-64.
[3]罗拥军,李晓乐,孙如祥.负载均衡算法综述[J].科技情报开发与经济,2008,18(23):134-135.
[4]戴艺,苏金树,孙志刚.基于流映射的负载均衡调度算法研究[J].计算机学报,2012,35(2):218-228.
流媒体服务器 篇8
关键词：流媒体服务器,安卓播放器,视频点播,视频压缩
全球每天有超过1亿部Android设备被激活,安卓手机因其开源操作系统、开源社区支持、强大的开发工具而占据智能手机主流。但是众所周知,手机流量资费较高,人们用手机收看视音频节目会受到相应数据流量套餐的限制。基于智能手机在流媒体服务方面,使用用户多、流量资费高的现状,推出了一种基于嵌入式流媒体服务器的视频点播系统。为了满足广大用户观看高清、超高清视频的需求,要求高清、超高清视频在流媒体服务器传输过程中,低功耗、失真小,本系统设计了一种对原始图像帧无损压缩算法,通过图像压缩编码技术来降低图像冗余度,从而减小图像的存储容量[1]。相应的,需要开发新的Android手机播放器,对本发明中特定的编码技术进行解码,正常播放视频节目。
本文设计的多功能视频点播系统,基于嵌入式流媒体的服务器[2]既可以存储外接设备的视音频,又可以对外接公共场合摄像机得到的原始视频进行无损压缩存储,最终安卓手机客户端制作两个界面,一个是播放列表、一个是监控列表。播放列表供人们自由选择流媒体服务器存储的视音频,监控列表显示在商场或景区一些人口密集场合,方便用户快速选择距离近且人少的场地,另外也可为工作人员(保安、安防人员)提供公共场所安全情况视频展示,方便不同客户自由点播自己喜欢的节目或者用手机接收视频画面,清楚了解商场、景区等动向,方便出行和工作。在计算机网络中,多播[3]技术是在一个单一传输源,同时把消息或信息传输到一组目标计算机。多播是实现IP组播最常用的,经常用于互联网协议(IP)的流媒体和网络电视的应用程序。多播概念的实现产生于路由级别,路由器在发送数据信息到多播目的地址时,创建最佳的分配路径。类似多播的应用还有视频流媒体服务的需求、网络游戏、音频或视频会议新技术等。因此,选择多播技术和手机客户端接收节目信号相结合,发明一个低成本、免流量资费、终端用户多、便携式的设备是一项有意义的推进。
1 现有技术阐述与分析
已有技术1:无损压缩算法JPEG-LS,把当前像素邻近的几个已编码像素作为其上下文进行预测,得到预测残差,并对这些残差采用Golomb指数编码。该算法只用了上下文预测与Golomb指数编码,没有用DCT变换和算术编码,算法简单,易于硬件实现。
已有技术2:CALIC算法,采用GAP(梯度自适应预测器)对图像进行预测。根据预测邻域水平方向和垂直方向的局部梯度来判断图像是否存在边界以及边界的强弱,并根据计算的结果动态调整预测函数从而得到预测残差。对预测残差采用基于CACM++的自适应算术编码器进行编码。
已有技术3:一种媒体内容共享系统中的媒体文件点播方法,关键技术是EPG在运营支撑系统OSS和终端之间作为媒介,配合URL,实现终端向分布式流媒体发送媒体文件服务请求后,可以正常接收到点播媒体文件的文件流并进行点播。
已有技术4:一种点播多媒体消息业务的方法及系统。在数据业务管理平台、多媒体消息中心、用户之间开展点播源的传输,又设计了多媒体消息中心对接收到的多媒体消息进行判断的功能,根据用户的需求,决定点播流程是继续或终止。
已有技术5:智能手机已经开发了很多播放器。
然而现有技术都存在一些缺陷,由此更体现本系统提出的必要性。
已有技术1的缺陷:压缩率比较低。本发明块级/分层自适应帧内预测、残差系统半定长变长编码(Variable-Length Coding,VLC)、控制字段Huffman变长编码的多技术协作无损压缩使压缩率能达到50%左右。
已有技术2的缺陷:是对整幅图像进行预测,预测效率较低。本发明中采用的宏块自适应帧内预测,支持两种预测模式,即块级预测和分层预测。其中,块级预测支持水平和垂直方向的块间和像素级预测,分层预测支持水平和垂直方向的平均和复制预测。每个宏块根据残差编码比特和控制信息比特,优先选择预测效率高者为最优的预测模式,提高预测效率。
已有技术3和4的视频点播过程比较繁琐,不适合在公交、电梯、景区、商场等小型场合人们的日常生活需求。本发明装置简单,成本低,免流量资费,终端用户多,采用便携式的设备,方便小型场合以简易且价格低廉的ARM板作为服务器,广大人民群众用自己的Android手机作为客户端,实现在智能手机上,多个客户端同时免流量接收服务器本地或外接设备推送的高清、超高清视频,不同客户可以自由点播喜欢的节目或者用手机接收的视频画面清楚了解商场、景区等的动向,方便自己的出行和工作。
相比已有技术5,本发明开发的播放器针对特定的应用,即服务器上的流媒体文件、对某些特定场合录像的原始视频点播,能满足特定的需求,即在电梯、车载、公交、小型广场、景区等场合广大用户的利益。可实现特定功能,即能满足对服务器已有视音频文件和经无损压缩算法编码得到的视频解码回放。
2 系统整体方案
本系统涉及多播技术、原始图像帧无损压缩、UDP[4]控制流、RTSP[5]传输流、流媒体服务器、智能手机点播的系统方法,最终能达到在一定区域内,多个手机自由、免费、快速地点播服务器本地或外接设备视音频。主要步骤有:1)将Linux系统内核设置为支持多播技术;2)ARM板本地或外接设备存储的原始图像帧以宏块为预测编码的基本单元,支持宏块随机访问,实现无损压缩;3)压缩编码后的视频节目及外接设备存储的完整视音频通过Wi Fi网络适配器传输给安卓手机客户端,多个客户端通过UDP和RTSP协议实现控制和流传输;4)多个智能手机终端接收到数据资源,显示节目列表,点播视频进行信源解码和回放。系统结构如图1所示。
3 基于嵌入式流媒体服务器的视频点播系统
3.1 视频点播步骤
首先,ARM板搭建多播环境,允许多个客户端同时接入流媒体服务器,编译、安装live555,建立RTSP协议流传输连接[6]。多播是一种网络协议操作,允许一个源同时发送数据包到多个端点。多播要求高带宽,点到面应用,如分布式计算、高定义视频流、存储区域网络。从传统意义上讲,多播是实施电子在路由器的网络层中,通过复制和存储在缓冲区中的数据包。然而,通过在网络协议栈的光层迁移组播操作,基于分组的多种功能可以较低的成本得到支持。ARM开发板结合live555,它是目前实现rtsp协议使用最多、用途最广的开源代码,而且它的更新速度很快,方便研究人员根据不同需求开发新功能。Live555已经实现了基于UDP和TCP的传输,支持MPG,MKV,H.264,AMR等文件的点播,有服务器端和客户端两种实现方式。由于本系统是在一个多播环境下实现的,所以需要对其中Group Sock和Live Media两大模块进行设计和编译,生成可执行文件live555Media Server_IMX6S,在后续过程中调用。
流式传输是流媒体技术实现的重要部分。为了保证数据能够正确完整地传输,在传输之前要对流媒体服务器外接设备传送的原始视频进行预处理,即对原始视频采取高效压缩。本文中采用块级/分层自适应帧内预测、残差系统半定长变长编码(Variable-Length Coding,VLC)、控制字段Huffman变长编码的多技术协作无损压缩系统方案;提出的自适应高效帧内预测,支持不同区域不同小块自适应编码,支持宏块级数据随机访问;并基于编码比特消耗最小化的原则,在预测效率和预测残差编码比特效率之间平衡。对原始视频进行无损压缩包括两大步骤:预测和熵编码。1)基于宏块的自适应帧内预测。它支持两种预测模式,即块级预测和分层预测。其中,块级预测支持水平和垂直方向的块间和像素级预测,分层预测支持水平和垂直方向的平均和复制预测。每个宏块根据残差编码比特和控制信息比特,优先选择预测效率高者为最优的预测模式。2)基于小块的半定长变长编码。它将预测残差自适应划分为8个变长的编码区间,并用相应的字段标识,对这些字段采用Huffman编码,并将每个区间内的残差自适应分为不同大小的块,块内采用定长编码[7,8,9]。高效压缩算法结构如图2所示。
基于对视频进行高效压缩使数据量减少,且对视频不要求分组顺序到达,本文ARM系统实现流媒体服务器,选择在数据传输过程中延迟小、数据传输效率高的Socket的UDP双向通信。虽然UDP是无连接通信,但是本系统实现发送端和接收端的双向通信。多个智能手机终端通过UDP协议获取服务器所有高效处理过的视频包含路径、名称的列表。设计在手机端列表只显示名称。
通过Wi Fi网络适配器实现一个Wi Fi连接热点,根据手机端列表的路径找到视频节目源,基于RTSP流媒体传输协议在客户端(智能手机)和流媒体服务器之间建立流媒体传输连接,实现视音频数据流(RTSP数据流)到手机的传输。服务器端和手机终端播放器通信流程,如图3所示。
设计Android版本播放器支持对视频的编码方法。通过access(访问)、demux(解复用)、decode(解码)、output(输出)主要步骤处理手机端接收到的节目信息流,制作两个视频点播界面,即播放列表和监控列表。收听视音频的用户可点击播放列表,播放高清、超高清视频节目,完成低功耗视频点播;在商场、景区的用户点击监控列表,对周围要去吃饭或游玩的场所有大致了解;安保或其他工作人员也可以通过监控列表画面快速知晓公共场合的突发事件,有利于提高工作效率。
3.2 视频点播效果及分析
用户安装本系统的安卓手机播放器后,在一定范围内,打开网络流界面,输入服务器的IP地址,基于UDP协议服务器在手机端打印出播放列表和监控列表[10],当一个或多个客户端选择资源后,通过UDP协议将控制信息发给流媒体服务器,通过建立的RTSP连接,手机端接收RTSP数据流正常播放视音频。如图4所示。因此,本文多功能视频点播系统产生的有益效果主要有以下几点:1)对ARM板及其外接设备的原始图像无损压缩,为整个装置低功耗做基础,达到视频传输速率快、失真少的目的;2)在服务器的Wi Fi连接热点内,智能手机终端出现服务器视频节目选单,包括外接设备传输到服务器的视音频,和录像设备传输到服务器并经过压缩的文件,手机播放器显示播放列表和监控列表;3)多个智能手机可同时接入流媒体服务器,通过播放器显示的选单,不同用户分别选择不同的资源,或同时选择同一个资源,可随时切换,安卓手机能够对无损压缩编码的视频源解码,正常流畅地播放文件,实现免流量接收视音频。
4 小结
本文采用的便携式流媒体服务器视频点播低功耗装置,解决了服务器外接公共场合摄像机得到的原始视频如何进行无损压缩、压缩编码后的数据和流媒体服务器外接设备存储的视音频流如何传输给智能手机、手机客户端如何接收节目信息列表并对压缩编码视频源解码播放、以及怎样实现多个客户端同时点播视频等难题,实现在没有互联网接入的情况下,多个用户同时接收大量视音频。不仅减少安卓手机用户的流量消耗,还可以给不同客户的工作或游玩带来更快更明显的便利,所以,本系统具有较高的推广和应用价值。
参考文献
[1]KIM J,KYUNG C M.A lossless embedded compression using significant bit truncation for HD video coding[J].IEEE transactions on circuit and systems for video technology,2010,20(6):810-849.
[2]曾金.嵌入式流媒体服务器的设计和实现[D].南京:南京邮电大学,2011.
[3]赵鹏.视频流媒体多播系统技术的研究[D].大庆:大庆石油学院,2008.
[4]王艳芳,戴永.基于UDP的数据可靠传输技术研究与应用[J].计算机工程与应用,2010,46(3):105-108.
[5]刘大红.基于RTSP流媒体服务器的设计与实现[D].西安:西安电子科技大学,2013.
[6]谭石坚.嵌入式VOD系统的设计与实现[D].广州:华南理工大学,2010.
[7]XIN L,MICHAEL T O.Edge-directed prediction for lossless compression of natural images[J].IEEE transactions on image processing,2001,10(6):813-815.
[8]OKANO F,KANAZAWA M,HAMASAKI K,et al.Ultradefinition television system with 4000 scanning lines[R].London,UK:Broadcasters Broadcast,2004.
[9]NIKARA J,VASSILIADIS S,TAKALA J,et al.Multiplesymbol parallel decoding for variable length codes[J].IEEE transactions very-large-scale integration systems,2004,12(7):676-685.
流媒体服务器 篇9
1 服务器系统模块
异步事件驱动框架可动态装载多种流媒体协议管理模块、文件管理模块和业务管理模块等,这样可屏蔽系统平台中网络操作细节,降低了系统的复杂性,上述模块还可被替换进行在线升级,整体结构如图1所示:
2 服务模块化管理
流媒体服务器由一个模块管理器及其所管理的模块组成,其模块如图2所示。
流媒体服务器启动时,SvcModuleManager对象就装载了相应内置的模块和文件信息管理的外置模块,模块都有ID和name来标识,从SvcModule_IF继承的模块受到了SvcModuleManager的控制,继承后的模块都引用计数且有相互依赖关系,也是通知所有引用此模块的其他模块,其引用计数加1。脱离控制时减1直到0为止,同时脱离所有引用此模块的其他模块,此模块才会真正被卸载。
3 异步事件驱动框架的系统设计
3.1 框架概述
由WorkEnv和TaskObj两对象组成流媒体服务器的异步事件驱动框架是为了满足高可扩展性、高网络I/O、高磁盘I/O而开发,也可简化线程同步与互斥带来的复杂性问题,其中前者是容器,后者则是此容器中的具体任务对象,如图3所示。
TaskObj在WorkEnv对象中注册事件后主要负责处理请求和检测事件,将检测到的事件交由各TaskObj对象进行处理,当WorkEnv检测到事件回调时说明保证了事件的互斥和同步,另外,用户具体的应用任务对象也可以从TaskObj中继承下来,同时重载TaskObj的一个或多个事件处理函数,实现具体的事件处理功能。
为充分利用多线程的处理能力,整个服务器系统可创建多个WorkEnv对象,不同的Taskobj之间可通过消息机制进行交互,将复杂的对象间交互简化成消息的发送和异步消息接收处理,同步互斥问题由WorkEnv对象处理,以达到负载均衡。另外,由于引入高网络I/O、高磁盘I/O和定时器等多种异步消息处理机制,Taskobj的事件消息处理不需要再去执行阻塞操作,使整个系统的响应速度得到保证。
3.2 异步事件注册与调用
WorkEnv对象中包括事件的注册与检测,但如果同时注册时需要使用多个框架,因此需要统一在同一框架下,而异步事件驱动框架正好可以派上用场,首先寻找一个负载相对较轻的WorkEnv对象调用其EnterWorkEnv()函数并加入到其中,然后将具体的异步事件加入操作并调用Taskobj的handle_open()事件处理函数。处理过程中还可通过调用RegisterTimer()来完成定时执行的操作,调用handle_timeout()来处理定时时间的完成。
在异步事件中网络I/O主要设计有两种形式,一是检测状态:TaskObj对象通过调用RegisterSockEvent()函数来登记状态检测事件,包括可读、可写和有特殊的数据。二是网络操作完成检测:当读操作时Taskobj调用RegisterSockRecv()函数用来注册网络读事件,并可以指定缓冲区最小和最大数据量,当进行写操作时TaskObj对象调用访问RegisterSockSend()函数用来登记注册网络写操作,还可确定网络输入输出缓冲区和发送的数据大小,一旦数据发送完毕后再调用handle_sock_send()事件处理函数。
在异步事件中磁盘I/O的设计主要是考虑延迟,这种延迟会放缓线程的运行,也就是影响事件的及时回调访问和磁盘吞吐量,而如果采用异步事件方式来处理磁盘I/O,其效率将大大提升。当磁盘数据输出时可让TaskObj对象调用访问RegisterDiskRead()登记磁盘读事件,并说明文件读取的位置、数据量及存放的缓冲区,完成后WorkEnv对象回调TaskObj对象的handle_disk_read()事件处理函数。
在异步事件中用户自定义消息事件的设计也尤为重要,比如对象间可通过发送自定义消息进行通信,避免直接的函数调用,为了减少TaskObj对象间相互的依赖关系,可以将之解耦,这样也减少了并发访问带来的数据互斥和同步。而且通过自定义消息通信也使整个框架保持高度一致。另外,当TaskObj对象需要向另一TaskObj对象发送自定义消息时,前者对象调用WorkEnv中的SendMessage()函数发送消息,而后者对象会在所在的WorkEnv中回调handle_message()函数进行处理。因此用户自定义消息事件的接收不需要再事先向WorkEnv对象注册。TaskObj不再进行事件处理时需要通过访问LeaveWorkEnv()函数来显式退出WorkEnv对象,并释放与此TaskObj对象相关的内部资源。
4 异步事件驱动框架的实现
异步事件驱动框架中WorkEnv对象保存了所有由这些TaskObj所注册的事件信息。这些事件的检测由一个主线程来完成,而这主线程主要又是通过调用epoll()来检测网络事件,同时此主线程也负责所有事件的回调。并能够直接返回发生socket_fd事件,无需将所有socket_df事件传递到内核中进行遍历,避免了并发连接较多时遍历所有socket_fd检查带来的沉重开销。另外,定时器事件也可以通过epoll()调用的超时参数来完成,在没有其他事件提前触发,到了超时时间epoll()函数调用也会返回。
而异步磁盘I/O的请求和检测则由另外一个辅助线程来完成,由于磁盘I/O操作相对较慢,这样辅助线程执行中再转移到主线程中的分派会有些延迟,磁盘异步I/O中磁盘读写操作由io_submit()来提交,检测请求由调用io_getevents(来完成,即磁盘I/O的读写与检测是分开的,两者通过采用异步的方式在合适的时候通知主线程进行分派处理,使用磁盘异步I/O时的单线程还能够同时提交多个磁盘I/O访问请求,故可提高磁盘的I/O效率。
5 异步事件框架的应用
单个处理流程中,此框架被分解成不同的Taskobj对象和状态,而对于状态要分析状态转换关系以及在各个状态下所需要注册的不同事件和不同的处理方法,这样增强各个Taskobj对象的独占性,另外还可以将一些旧有系统的代码和一些会产生阻塞操作的调用加入到独占的只为对应TaskObj服务的WorkEnv中,当这些阻塞操作不会影响到其他Taskobj的响应时,其他Taskobj对象可以通过消息通信机制向Taskob发出操作请求,并异步等待Taskobj的应答消息。
6 结语
介绍了Linux下流媒体服务器的内部模块结构,并分析和解读了异步事件驱动框架的重要性,要想提升服务器的性能,异步事件驱动框架的设计必不可少,此框架下的流媒体服务器主要有如下特点:
(1)整个流媒体服务器具有较高的性能,充分利用网络和磁盘的最大读写和回调能力,支持更多的并发用户,瓶颈问题逐渐减少,线程之间没有相互阻塞,不存在线程相互等待的问题等。
(2)linux流媒体服务器具有良好的可互操作性、可扩展性和独占性,可以通过增加各种模块,提升扩展支持,方便与其他系统对接。由于采取了模块化的设计,所以可以通过加载不同的业务模块来支持不同的业务需求。
参考文献
[1]全生,舒继武,毛希平,郑纬民.基于VLS系统的负载动态平衡设计与实现.计算机研究与发展,2004,41.
[2]Robert Love.“Linux Kernel Development,Second Edi-tion”.Pearson Education,2005.
[3]ISMA 1.0.1:“Intermet Streaming Media Allinace Implemen-tation Specification.Version1.0.1”,2004.
[4]曾立安,凌力.基于Lniux的消息驱动Socket模型.计算机工程,2003,19.
苹果将于秋季推电视流媒体服务 篇10
谈判的主要问题在于苹果的三七分成方案。根据该公司一直以来的分成方案,苹果将会分走服务营收的30% 。不过报道称,谈判正在迅速取得进展,因为苹果希望能在今年深秋推出该服务。
迪斯尼和CBS电视台将会是首批签约的公司,并将会与苹果签订合作协议。同时苹果希望能获得迪斯尼旗下的ESPN和Discovery频道的内容,还希望能将一些地区性在线电视台纳入协议中。据称,苹果正在寻求方法能够快速与遍布全国的地区性电视台达成协议, 而不用其一家一家地去谈判。
为明星服务的社交媒体 篇11
这个小世界的看门人是埃利斯（Steven Ellis），他同时还是音乐版权公司Pump Audio的创始人。埃利斯表示，位于洛杉矶的创新艺人经纪公司（CAA）找到他来做这件事，因为他们意识到，需要通过一个集中的方式来对旗下艺人所发布的各类社交媒体内容进行管理。2010年3月，该经纪公司委托埃利斯设计了这个平台，并为他提供了种子资金。Whosay于当年9月正式上线，凭借CAA在艺人内部的宣传，该网站的艺人使用者数量一直趋于稳定上升。同时，WhoSay还为那些非CAA旗下的艺人提供服务，例如凯文·贝肯（Kevin Bacon）与格温妮丝·帕特洛（Gwyneth Paltrow）。
埃利斯说：“我们认为社交媒体具有十分大的价值，并且我们的客户有能力制造一个优秀的媒体圈。我们尝试着让我们的客户能够随时随地、随心所欲地发布社交媒体内容。”
通过WhoSay发布的每一条社交媒体内容后面都伴随有一个简化的URL地址，这个地址会指引粉丝跳转到另一个包含这个明星的照片、视频以及文字内容的网页上。这个页面由WhoSay进行优化并掌控。与其他诸如??HootSuite和TweetDeck等类似的平台不同，WhoSay正在积极与 ESPN作、雅虎合作，利用他们的内容对客户进行推广与宣传。另外，WhoSay还具有国际功能可供选择，使用者可以通过它对中国等其他国家和地区的社交网络进行管理。
如今，WhoSay已经成功吸引了超过900个明星使用者，这些人都经过了埃利斯对他们的影响力审核程序，这么多的明星使用者也吸引了一部分投资者。尽管公司现在还没有清晰明确的盈利模式但他们仍然成功地通过两轮融资从亚马逊以及位于纽约州特洛伊市的风险投资公司High Peaks Venture Partners处融得了共计700万美元的投资。去年10月，曾投资Facebook、LinkedIn以及Pandora等互联网企业的风投公司Greylock Partner也在WhoSay的第二轮融资中注资，具体投资数目不详。该公司的合伙人大卫·斯泽（David Sze）认为，如果WhoSay能够成为一个自创内容的明星信息网站，那么它的盈利数目将十分可观。
斯泽说：“从长远来看，WhoSay拥有很多种收入方式，例如广告、增值服务、基于产品的服务等方式。”
的确，正如他们的口号所说，“创造明星内容，盈利不再是梦（create celebrity content, and the money will follow）”，WhoSay现阶段主要是要精力集中在基础架构建设上，这项工作要求他们取得更多的发布许可，并且需 要他们不断的努力与明星的代理人、经纪人以及宣传人进行合作，并且不断完善自身服务用让使用这项服务的明星们能够更简单便捷地用WhoSay发布内容。
埃利斯说：“我们的工作顺序有点不一样。先使我们的服务对明星来说简单易用，然后让粉丝们以最简单的方式发现明星们发布的内容。然后，才是对明星们发布的内容进行优化。” 译/鲁行云
流媒体服务器 篇12
随着电子消费产品技术的不断发展, 越来越多的设备能够产生媒体数据, 例如手机的拍照和拍摄功能、数字电视和机顶盒等的节目录制功能等, 均能产生丰富多彩的媒体数据, 而PC更是媒体数据的集中地。因此, 对于在PC、家电和移动手持设备这些不同种类的设备之间方便地进行数据共享的需求越来越强烈。同时, 随着网络技术的不断进步, 越来越多的设备也具备了接入网络的能力, 这也就为进行设备互联提供了基础。
在不同设备之间实现数据共享的传统实现中, 往往需要进行一些复杂的设置工作, 而且对于不同的设备, 因为原件和软件的巨大差异还会导致设置工作各不相同, 所以这些配置工作对于普通用户来讲无疑是无法接受的。因此, 微软公司在1999年提出了新一代的通用即插即用 (Universal Plug and Play, 缩写成UPn P) 。
UPn P技术实际上扩展了传统单机的设备和计算机系统的概念, 在“零配置”的前提下提供了UPn P智能设备之间的寻址、发现、控制和其它信息的交换等互动操作功能。对于用户来说, 支持UPn P的设备做到了接上就能用, 给办公和生活带来了极大地方便;对于设备提供商来说, 因为UPn P是建立在互联网标准和技术之上的, 因此它具有广泛的适用性, 可以运行在几乎所有的操作系统平台之上, 可以使用C/C++, Java等各种语言进行软件的开发, 所以能够在较短时间内形成产品, 降低开发成本, 因此UPn P在提出之后获得了广泛的支持。
1 系统结构
通过对系统的分析, 将UPn P媒体服务器结构设计为如图1所示的三层结构:
(1) UPn P接口层:对Device和Service进行了抽象, 封装了UPn P的基本操作实现, 实现了功能类集, 包括用于实现UPn P基本功能的SSDP、SOAP、GENA、HTTP协议封装、XML解析及Socket封装等。
(2) UPn P AV层:对Device和Service进行了实现, 其中Service包含内容目录服务 (Content Directory Service) 和连接管理服务 (Connection Management Service) ;另外该层还实现了功能类集, 包括对MP3、JPEG、MPEG等格式文件的解析功能。
(3) UPn P应用层:媒体服务控制器是用于对媒体服务器进行控制的, 包括启动、关闭服务器和响应用户输入等功能, 其中启动过程需要指定共享目录的路径。
2 系统实现
此项目是在Linux Redhat 9.0操作系统上使用vi、gcc/g++、make等工具完成开发的, 底层使用了Intel公司提供的UPn P协议栈。该系统核心模块的类图设计如图2所示。
图中的类按照图1中三层体系结构分布:CMedia Server Controller处于应用层, 负责系统的启动和退出及响应用户输入;CAVMedia Server处于AV层, 是系统的核心部分, 主要负责系统启动时的初始化工作 (文件检索、UPn P网络初始化等) 、处理用户的命令和响应来自网络的请求。系统运行过程的流程如图3所示。
3 系统测试
系统开发完成后, 将程序部署在台式机上进行了测试, 测试结果如下:
(1) 先启动控制点, 然后启动媒体服务器, 通过控制点可以发现该媒体服务器;
(2) 先启动控制点, 然后启动媒体服务器, 控制点在发出M-Search请求之后可以收到来自该服务器的回应;
(3) 控制点可以获得该服务器设备的设备摸索文档;`
(4) 控制点可以浏览服务器上共享的文件内容和文件的详细信息;
(5) 控制点可以将服务器中的媒体文件 (MP3和JPEG格式) 用网络上的另外一个媒体播放器 (Digital Media Renderer) 来播放。
由此可见, 该媒体服务器已符合UPn P设备的要求。
4 结束语
该媒体服务器已基本实现了媒体共享的功能, 但是距离实用还有很大的距离, 主要体现在: (1) 该媒体服务器目前只支持HTTP方式的连接, 不支持RTP连接方式; (2) 该媒体服务器对文件的管理机制是在启动的时候扫描整个共享目录, 如果文件数量巨大, 则扫描过程会非常耗费, 会导致设备启动缓慢; (3) 支持的媒体类型还比较有限。
摘要：UPnP是一种构建于互联网标准技术 (如TCP/IP, HTTP, XML等) 之上的、用于实现网络设备智能互连以及对设备进行控制的标准规范。在简要介绍了基于UPnP协议的基础结构和工作原理的基础上, 给出了应用UPnP技术及其AV架构实现媒体服务器的实例。
关键词：UPnP,网络设备,媒体服务器
参考文献
[1]UPnP AV Architecture:0.83For UPnP Version1.0June12, 2002.
[2]ConnectionManager:1Service Template Version1.01For UPnP Version1.0June25, 2002.
[3]ContentDirectory:1Service Template Version1.01For UPnP?Ver-sion1.0June2002.
[4]李平均, 申健.基于UPnP的AV体系结构的设计与实现[J].计算机工程与设计, 2007 (4) .