微软Media Services助力技术沙龙现场直播

【51CTO独家特稿】51CTO.com作为中国最大的中文IT技术网站，为便于一些免费技术讲座和沙龙活动视频发布，技术部门和编辑部决定采用视频直播的方式与更多的网友分享，那么如何才能满足这样的视频直播需求呢？

需求分析

首先，对于51CTO门户网站上搭建视频直播的应用，需要将音视频信号实时编码处理发送给流媒体服务器，由流媒体服务器提供直播、点播服务，而考虑到易用性方面，首要的要求就是客户端不用下载专用播放器，采用操作系统中Windows Media Player便可观看直播服务。

其次，直播服务器用于对视音频节目要支持编码设置、录制播放时间表制定的管理，播出后的节目内容上载管理，要支持直播编码器的选择控制管理，用户的权限管理。另外，不但可将现场音视频信号进行网上直播，还要同时还可录制正在直播的节目。“最最最”重要的一点，是要在直播的时候支持一些后续活动的预告片的播放。

如果你阅读了前面几篇Media Services的内容，你一定相信“Windows Media Services 2008 + Windows Media encoder编码器”可以胜任这个平台吧？没错！看来我们唯一要分析的就是“组播”和“插播预告”了。

技术分析

IP组播，英语原文IP Multicast ，也可译为“成组通信”。下面来看一下这个特殊的协议，我们知道IPv4定义了3种IP数据通信方式：点点通信、全网广播、组播。点点通信是指两个IP地址间进行的数据通信，而全网广播是指在IP子网内向所有网内IP地址以广播的方式发送数据包，所有子网内的IP站都能收到全网广播，那么组播就是指在IP网上对一组特定IP地址进行数据传送，是居于前两者之间的通信方式。多媒体视频流对数据可靠性要求不高，适当的数据丢失不会过多影响视频播出的实际效果。虽然多媒体视频流对网络传输延时和抖动比较敏感，而IP组播在网络中延时与抖动是很少的，所以用IP成组通信来传输IP视频信号是可行的。

在一个单播（Unicast）环境里，视频服务器依次送出 n 个信息流，由网络中的用户接收，共需要 n x 1.5Mbit/s 的带宽；如果服务器处于 10Mbit/s 的以太网内， 6~7 个信息流就占满了带宽；若在一个高速的以太网里，最多只能容纳 250~300 个 1.5Mbit/s 的视频流，所以服务器与主机接口间的容量是一个巨大的瓶颈。

而在一个组播（ Multicast ）环境里，不论网络中的用户数目有多少，服务器发出的一个视频流，由网络中的路由器或交换器同时复制出 n 个视频流，广播到每个用户，仅需 1.5Mbit/s 的带宽。 可见， IP 组播能够有效地节省网络带宽和资源，管理网络的增容和控制开销，大大减轻发送服务器的负荷，从而高性能地发送信息。

另外，组播传送的信息能同时到达用户端，时延小，并且网络中的服务器不需要知道每个客户机的地址。所有的接收者使用一个网络组播地址，可实现匿名服务，并且 IP 组播具有可升级性，与新的 IP 和业务能相兼容。

另外，要在网络上实现组播应用，必须要有相应组播设备和协议的支持。按照组播协议的分类，在三层的组播协议主要有DVMRP、PIM和IGMP等，而在二层的组播协议主要用CGMP(Cisco Group Management Protocol)和IGMP监听。三层组播协议主要用于组播信息的转发，二层组播协议主要用于抑制局域网上多余的组播信息。在路由器及多层交换机上一般实现三层的组播协议，而在不具备多层交换的交换机上一般只能实现二层组播协议。

举一个例子，我们假设51CTO内部网络的设备都支持组播管理，如果要实现基于Media Server的组播，不但要在Media Server上进行配置，还需要在交换机启动路由协议PIM，以及启动CGMP协议。例如启用组播路由需要执行在全局模式下配置ip multicast-routing启用组播路由：Switch(config)# ip multicast-routing ，然后再接口配置模式下配置ip pim dense-mode/sparse-mode/sparse-dense-mode，例如Switch(config-if)# ip pim dense-mode 。

搭建组播平台要求组播源和组播组成员及其两者之间的底层网络都必须支持组播，我们来看一下实现组播的必要条件：

主机的TCP/IP支持发送和接收IP组播数据包；

主机的网卡支持组播；

有一套用于管理成员加入、离开和查询组成员的组管理协议，如Internet组管理协议(IGMP)；

有一套IP组播地址分配策略，并能将IP组播地址映射到组播MAC地址；

有支持IP组播的应用软件；

所有介于组播源和组播组成员之间的路由器、交换机、TCP/IP协议栈、防火墙等均须支持组播。

针对这个案例，我们看到一个比较难搞定的问题，这就是51CTO的技术人员无法控制所有收看客户端的网络设备，因此实现广域网环境下的组播几乎是不可能的，但如果是在内网环境下实现组播还是可行的。很遗憾，我们只能选择单播技术作为直播发布的属性。

广告和插播技术分析

下面来看看关于预告片的需求，其实这说起来就等同于广告。Windows Media Services 为预先录制的内容和直播内容提供了多个广告选项供我们选择：

包装广告：在用户查看直播内容之前、之后播放的流广告。

插播广告：随内容一起插入在播放列表中的流广告。你必须通过播放列表来使用插播广告。

横幅广告：显示在播放机上的与流内容无关的静态或多媒体广告。

当然，光有广告还不行，我们还可以使用策略来控制用户接收广告内容的方式。这包括：定义事件和控制播放列表的属性。对于事件来说，我们可以使用某个事件来触发到特定广告的切换。例如，在实时广播中，可以使用某个事件在区域性广告中插入本地广告，反之亦然。而对于播放列表属性，则可以配置播放列表属性以控制用户对广告的体验。例如，如果将 noSkip 属性设置为 True，则用户播放器上的快进和搜索控制会被禁用。若要使用户继续接收播放列表中的内容，必须播放完广告。

针对本案例中的直播项目，Media Services采用包装广告是最为适宜的，因为无论用户在哪个点加入广播，包装广告都会播放，用户都会看到预告片的内容，包装广告是理想之选。

【51CTO独家特稿，合作站点转载请注明原文译者和出处。】

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!