aspne视频点播系统的设计与实现

aspne视频点播系统的设计与实现

网络技术和通信技术的发展扩大了网络面积，丰富了网络服务。视频点播网站,网上教学正在成为新的网络宠儿。本文正是设计和实现了基于流媒体技术的医学教学视频点播系统,系统是下一代互联网的医学教学科研平台的子项目,为各高校师生提供教学服务。1流媒体传输方式流媒体技术主要是将声音,影像,动画等数据分成一个个压缩包,向用户提供连续的,实时的传播,而不必等到整个视频文件下载完成才能观看。通过缓存技术提供流畅的视频播放,并且大大缩短了播放延迟,改善用户体验。流媒体的传输方式主要有顺序流式传输和实时流式传输。顺序流式传输顾名思义在连接建立后,服务器会按照数据在视频文件中存放的次序顺序发送给客户端,不会对数据做额外的处理,而且这种传输如果不加限制的话采用的是一种尽力交付的方式。由于顺序流式传输实现简单,传输协议采用Http协议即可,视频文件放在web服务器,不需要专门的流媒体服务器支持,网站和视频完全可以集成在一起。实时流式传输要求数据传输和用户播放是同步的,视频可以实时地被观看。服务器对于数据会分成视频和音频做额外的处理,因此需要特定的流媒体服务器支持,如RealServer,WindowsMediaServer。本文实时流式传输协议采用Rtmp,流媒体服务器为Red5。2视听编辑的解决方案2.1流的视频请求和视频管理整个医学教学视频点播系统采用Asp.Net3.5框架开发完成,实现基于Rtmp和Http协议两种传输方式。服务器包括静态服务器Nginx,动态内容服务器IIS7.0,Rtmp服务器Red5。Nginx是一款高性能web服务器,构建于最新的linux2.6内核之上,采用epoll模式来处理大规模的并发连接,并可以配置使用最新的NPTL线程库,传输效率不会随着连接的线性增长而下降,相比于其它服务器内存占用极小。Nginx主要用于处理静态页面和作为反向代理服务器,对于动态页面和视频文件的请求转发给IIS7.0处理。这样既加快了静态内容的处理速度,又保护了后台数据库的安全。IIS7.0对于所有的请求在进入HttpRuntime时,都会经过一系列注册的Module进行过滤,最后对于特定的请求交由指定的Handle处理。系统中通过配置WebConfig文件,将基于Http协议FLV文件的请求映射给FLVHandler,该类必须实现接口I-HttpHandeler。Red5是一款开源服务器,通过对数据包进行逆向工程的研究从而实现了Rtmp协议。主要功能是处理对于流媒体视频的请求,从FLV文件中提取出视频和音频,并将其打包成消息,在同一连接上传输不同的流,并支持客户端在点播时的各种操作命令响应。Flash播放器由ActionScript3.0编写,实现Rtmp和Http两种协议的视频请求和播放,系统提供给用户上述两种点播方案。整个播放器作为SWF文件嵌入到web浏览器中,用户只需打开网页便可观看视频,无需下载播放器。系统通信流程图如图1。视频文件统一为FLV格式,FLV作为目前最流行的流媒体视频格式,其形成文件小,结构简单,非常适合网络传输。FLV文件主要由一个文件头和许多Tag组成,Tag类型主要分为视频流,音频流和脚本流。由于视频信息和音频信息采用分开存放的方式,所以Tag中需要Timestap确保视频和音频同步。Tag中的数据区会指明该Tag的编码类。FLV文件格式如表1。2.2没有同时发挥作用的情况Rtmp协议提供了流媒体视频的高效率传输,可以构架在Tcp协议之上。客户端与服务器维持着一个单一永久的连接,支持实时交流。Rtmp主要为多媒体视频提供多路传输和数据分包服务,不仅支持视频和音频数据实时传输,还支持RPC(远程过程调用)。视频,音频,操作命令,共享对象,控制消息和其它类型数据被打包成一个个消息,并打上时间戳用于同步,不同类型的消息在不同流上传输,多个消息流又交错复用在同一个连接上。消息包括Message头和Message主体。Message头格式如表2。MessageStreamId主要用于在单一连接中识别不同的流,包括3个字节。MeaasgeType用于指明消息的类型,只有一个字节。类型1-7保留,用于传输控制消息,比如设置chunk大小,消息丢弃,用户控制消息等等。虽然通过设置MessageType可以将不同类型的消息在不同的流上传输,但Message也有其缺点,因此又将其分割成Chunk。分块可以将低优先级数据量大的Messag分割成小的Chunk,防止其阻塞优先级高数据量小的Message。流媒体传输的多路复用基于Message这一层,与Chunk无关。Rtmp在建立连接时首先要进行3次握手,类似于Tcp协议,不过是为了服务器和客户端统一协议版本信息。然后建立连接,创建传输流,设置chunk大小,发送数据。在视频播放过程中,如果用户拖动进度条,便会触发seek操作,该消息会通过与视频数据不同的流发送到Red5,Red5会解析控制命令,返回用户需要的数据。2.3视频摆动下载对于Http协议请求FLV视频文件,由IIS7.0响应。默认情况,如果客户端带宽良好,则下载速度远远大于播放速度。由于要保存下载的数据量比较大,所以文件会缓存到硬盘,播放器中的加载进度条显示下载到硬盘的数据。当用户拖动播放视频时,只能播放已下载的视频信息,如果将播放进度条拖动到超过加载进度条时,则播放停止。为了解决这一问题,在IIS服务器增加专门响应FLV文件的Class,即FLVHandler。首次请求视频文件,FLVHandler会读取服务器的视频文件通过网络输出流发送到客户端,播放器接收到视频数据后会调用回调方法onMetaData,该方法主要是从FLV文件中获取MetaData,也就是视频的基本信息,包括视频长度,帧率,实际宽度和高度等,其中还包括视频的关键帧信息。FLV的MetaData存储位置紧跟在FLVHeader之后,其Tag类型也就是上文介绍FLV格式中提到的脚本流,MetaData对于视频文件并不是必须的,但是在播放过程中要显示视频时间,对视频进行拖动则需要MetaData信息。视频拖动请求,如果拖动位置在播放器加载进度条之前,即该位置的视频数据已经下载到硬盘,则播放器会从本地硬盘读取数据进行播放。如果拖动位置数据还没有下载到硬盘,首先会从MetaData中找出距离拖动位置最近的关键帧,因为视频播放时必须从关键帧开始播放,关键帧包含了当前帧的全部数据。该关键帧所处位置会附在URL之后,然后向服务器重新发送一次视频请求。FLVHandler会检查请求参数,确保当前是视频拖动请求,如果参数值不为零且没有超过文件大小,则从该帧开始读取视频文件,也就是FLV文件中某一个关键帧Tag起始位置。如果这样就把信息发送到客户端,虽然有完整的视频和音频信息,但是播放器在读取时却无法识别这是一个FLV视频文件。因此根据FLV格式规定,需要在该帧之前添加FLVHeader。此时播放器接收到的网络流便是由FLVHeader和视频信息重新组合的FLV文件,但信息中缺少Metadata。当播放时检测到Metadata为空,不会触发回调方法onMetaData,因此元数据不会被更改,仍然为首次播放视频得到的Metadata。至此,基于Http协议的视频拖动播放结束。传输改进,由于在播放过程中下载和播放分离,下载速度又可能很快,例如用户在观看到5分钟时,30分钟的视频文件已经下载完毕,如果此时用户不想继续观看,则剩余下载的文件就会浪费。为了节省服务器带宽,所以FLVHander在传输视频流时,在前50M时会尽力交付,然后在传输一段视频便会执行Sleep操作,通过线程睡眠降低传输速度,维持在超过视频比特率50k-80k之间,保证正常观看。2.4视频视频正确下载Rtmp和Http协议都可以用于流媒体视频点播。Rtmp协议在整个播放过程中只与服务器建立一次持久性连接,客户端与服务器之间一直处于数据交互之中,视频传输和播放是同步的。Http协议在客户端请求连接后,服务器只负责发送数据,并不知道发送的数据是什么类型,也不知道当前视频播放进度。系统将两种协议结合在一起,用户可以根据自己需要选择不同的传输协议。当客户端网络带宽良好时,可以采用Rtmp协议播放,播放过程中可以随意拖动,由于只需要在连接上发送一个控制消息,所以开销少,响应速度快。当网络带宽拥塞不能满足实时播放时,可以选择Http协议,用户可以先暂停播放,让视频先下载到本地硬盘,等到下载足够的数据再进行播放。相同视频的不同协议请求会由不同服务器处理,但读取的是同一文件。两种协议在切换过程时,会记录当前播放位置的关键帧,所以在切换协议后,仍然会从该位置开始播放,无需重新观看,以达到无缝切换的目的。客户端带宽2mb/s,视频文件200mB,长度40分钟,分别采用Rtmp协议和Http协议播放,测试数据如表4。3.1模式1:主服务器整个网络架构包括主服务器,视频缓存服务器。主服务器包括整个系统的所有功能,可以响应页面和视频请求,解析动态页面,操作和维护数据库,管理所有视频的基本信息。主服务器采用1+1的冗余模式,分为Active和Standby,两者物理上为独立的服务器存在,属于同一个局域网。当Active服务器遇到故障时,Standby服务器马上变为Active模式。两者没有主次之分,可以在两种模式下相互转换,但同时只能有一个服务器为Active。视频缓存服务器只含有视频文件,功能单一,只能响应视频的点播请求。视频缓存服务器根据地理位置分散布置,所有服务器连接形成的网络尽可能地覆盖较大的地理范围,为不同地区的用户提供服务。3.2视频存储资源状态系统负载均衡以软件的方式实现,包含两条策略,主要目的是:首先用户点播视频时,从距离自己位置最近的网络边缘服务器获取数据防止出现网络拥塞,减少视频传输距离,从而降低网络传输消耗。其次,防止部分服务器因负载过高而不能及时响应请求,降低服务器宕机的几率。策略一:针对不同地理位置的视频点播请求会转发到不同的视频缓存服务器,转发流程如下:1)用户进入视频点播网站,选择需要观看的视频,发送该视频播放页面的请求。2)服务器判断该请求是视频播放页面,解析请求客户端的IP地址,通过IP地址库得到该IP的地理位置,地理范围具体到省级。通过视频缓存服务器登记信息找到距离该位置最近的服务器,写入将该服务器的IP地址,返回该页面。3)客户端浏览器解析返回页面,调用Flash播放器插件获取页面中的服务器IP地址参数,播放器向该服务器发送视频文件请求。4)视频缓存服务器获取请求信息,向客户端发送视频数据。第一条策略的不足就是负载均衡服务器在分发请求时并不知道各个服务器的状态,如果此时某一地区有大量用户在进行视频点播时,所有的请求都会由距离该地区最近的缓存服务器处理,请求量过大时则会达到带宽瓶颈。相反,某一地区如果只有很少用户视频点播,则该地区的服务器会一直处于空闲状态,浪费系统资源。因此需要第二条策略进行补充。策略二:所有视频缓存服务器后台都运行着一个监视进程,该进程主要用来查看当前服务器处理视频请求的并发连接数,工作流程如下:1)监视进程每过一段时间获取当前服务器的并发连接数,当并发连接接近该服务器的带宽瓶颈时,会发送一个类型为负载过高的消息通知主服务器。2)主服务器收到负载过高的消息时,会修改缓存服务器的登记信息,将该服务器暂时标记为失效,并替代为与该服务器地理位置最近的服务器,且该服务器无失效标志。此时该地区用户进行视频点播时,则会都转发到替代服务器上。3)当监视进程发现该服务器的并发连接数降低时,会发送一个类型为负载正常的消息通知主服务器。4)主服务器收到负载正常的消息时,会修改缓存服务器的登记信息,取消失效标记,移除替代服务器。负载均衡策略就是在防止网络拥塞,尽量降低网络传输消耗的基础上