媒体点播（通用12篇）
媒体点播 篇1
1 引言
流媒体(Streaming Media)是一种新兴的网络传输技术,在Internet中实时连续传输并播放音频视频等多媒体内容,用户端对数据流采用边接收、边播放、边丢弃的方式,减少了用户等待时间和网络传输压力,是实现直播点播系统的最新技术[1]。移动通信为流媒体技术提供了新的发展空间。《大学英语课程教学要求》将英语教学由阅读为主改为以听说为主,听的能力又直接制约说的能力,因此听力是英语学习的关键。随着现代教育技术的发展,传统放录音、对答案的听力学习模式必将被数字化学习所取代,移动学习和微型学习是当前研究的热点,也是未来数字化学习的发展方向[2]。开发英语听力流媒体点播系统,按用户需求主动获取英语听力内容,与传统的英语听力学习方式相比,创造性地将接受信息的主动性和选择性归于学习者,变被动学习为主动学习,倡导体验、参与、实践、协作与交流的主动式学习方法[3,4]。本文在吸收其他音频视频点播系统先进技术的基础上,结合多年英语听力教学经验以及英语听力学习的特点,基于流媒体技术设计英语听力点播系统,为软件开发提供全面的解决方案和技术支持。
2 系统结构设计
系统结构是系统组成的整体设计,为网络硬件、软件、协议、存取控制和拓扑提供标准。英语听力流媒体点播系统主要由综合服务平台、交换路由网络和用户终端三部分构成,系统结构如图1所示。
对图1的各组成部分简要描述如下[5,6]:
(1)综合服务平台,完成系统业务处理及数据存储功能。由五个服务器构成,在逻辑上相互独立,物理上可以是一个也可以是几个。门户网站提供用户操作界面及相关信息显示;业务处理服务器完成相关的数据处理及统计分析;媒体存储服务器需要磁盘阵列来保证数据的安全性和访问速度;媒体播放服务器用于完成格式转换以及媒体播放;内容缓存服务器用于远程播放时防止时延抖动。
(2)交换路由网络。由交换机、路由器、防火墙和网络媒介四部分构成。其中,交换机将每一个信息包独立地从源端口送至目的端口,避免和其他端口发生碰撞;路由器连接多个网络或网段的设备,将不同网络或网段之间的数据信息进行“翻译”,使相互之间“读”懂对方的数据;防火墙作为内部网与外部网之间的一种访问控制设备,保证网络信息安全;网络媒介包括局域网(连接服务器群组)、无线网络(3G/4G/Wi Fi)和有线互联网络构成。
(3)用户终端。用户通过终端设备完成系统操作功能,包括移动终端和固定终端两类。移动终端是指可以在移动中使用的设备,包括智能手机、i Pad、平板电脑等,支持i OS和Android等系统,运用移动设备通过无线网络实现点播;固定终端在具体的某一场所使用,通常指台式电脑或笔记本电脑,支持Windows或Linux以及其他操作系统,运用固定终端通过有线网络实现点播。
3 系统功能设计
英语听力流媒体点播系统由前台点播和后台管理两部分构成,系统功能结构如图2所示[7,8]。
前台点播以网页的形式显现给终端用户,任何接入网络的用户都可以访问,是否具有点播功能根据用户权限以及预存费用。用户注册成功后经过系统管理员审核即可登录进入系统完成相关操作。核心功能是通过“媒体搜索”功能找到相应的内容后使用“媒体播放”功能完成点播。辅助功能用于为用户完成相应的辅助工作,其中,用户充值,用户录入充值数据,上传缴费凭证等;在线服务,用户在使用过程中发现问题可直接通过该功能得到解答;公告显示,系统对一些重大事件或提示性信息当众正式公布出来;软件下载,用于下载支持英语听力流媒体点播的相关插件。
后台管理是为了保证系统运行以应用程序方式提供给管理员的管理和维护功能。音频视频资源是实现流媒体点播的物质基础,因此,核心功能是“音频管理和视频管理”,包括对音频视频资源的上传、归类、审核和删除等操作。系统还包括以下一些辅助功能:用户管理,对用户注册信息审核以及角色权限分配等操作;计费收费,根据时间或流量对用户点播的流媒体进行计费并从用户账户中扣除费用;系统配置,对软件系统的相关配置信息进行综合管理;公告管理,在系统后台进行公告发布、公告删除、公告变更等操作;信息维护,对系统的代码信息和基础信息进行的增加、修改、删除等操作;数据备份,为了系统的安全性定期对系统数据库或部分数据进行备份。
4 点播流程设计
点播流程是指点播程序的执行过程,点播程序根据点播流程进行设计,点播流程通过时序图表示。时序图(SD,Sequence Diagram)也称序列图或顺序图,是一种标准建模语言(UML,Unified Modeling Language)交互图,表示对象之间发送消息的时间顺序,显示多个对象之间的动态协作。英语听力流媒体点播系统点播流程的时序图如图3所示[9,10]。
对于图3所示的点播流程,共分为21步骤,有的步骤又分为几小步,综合起来点播流程为:“用户登录证→认证结果→点播请求→业务认证→查询余额→账户余额→认证结果→出错信息→生成UML→发送UML→启动播放器→请求内容→验证UML→出错信息→发送内容→开始计时→通知收看→开始收看→实时扣费→扣费信息→被动结束→结束计时→计算时间→结束通知→主动结束→结束计时→计算时间→计算扣费→计费反馈”。这些步骤分5大模块,图中用双点划线划分,各模块说明如下:
(1)身份认证请求模块。进入登录界面,输入用户名、密码和验证码,系统对用户身份认证,如果未通过身份认证则返回提示信息。如果通过身份认证,用户提出点播请求,并将请求信息传递给业务认证查询模块,如果未通过业务认证,则返回出错信息。
(2)业务认证查询模块。内部API调用以及HTTP协议、Cobra协议完成相应功能。根据点播请求进行业务认证,查询账户余额,如果账户余额不足则返回出错信息。如果账户余额可以支付系统设定播放时间的费用,则生成UML,传给启动播放模块。
(3)启动播放模块。接收业务认证查询模块发送的UML和附加的验证码,启动流媒体播放器,向播放服务器请求播放内容,播放服务器根据验证码验证UML,如果验证不通过则返回出错提示信息,如果验证通过则向终端用户发送流媒体内容。
(4)计算时间模块。播放服务器向终端用户发送流媒体内容开妈,将开始时间写入系统,被动结束或主动结束消息发出后,将结束时间写入系统。根据开始时间和结束时间计算点播时长,写入系统并作为计算费用以及考核用户学习情况的依据。
(5)收看计费模块。播放服务器将收看通知发送给业务综合处理系统后,开始播放流媒体内容,用户收听收看,系统进入实时扣费状态。如果账户余额不足以支付下一时段的点播内容,则播放被动结束,并向终端用户发出结束通知。用户如果主动结束播放,则完成计费扣费,并将费用结果反馈给终端用户。
5 结束语
英语听力点播系统是一种开放的学习方式,丰富了我国的英语学习模式,为开展终身英语学习提供了广泛的渠道[11]。本文基于流媒体技术进行的结构设计、功能设计和点播流程设计,解决了软件开发关键性的技术问题,能够为用户提供一种简洁、流畅、画面质量高的多媒体数字化学习途径,具有操作简单、功能强大、系统灵活等特点。但是,当网络传输速率低于流媒体播放速率或网络拥塞时,会造成播放的声音、图像时断时续,严重时甚至停顿,必须处理好这些因素以使点播效果更好。本系统的成功运用,对于强化英语思维能力训练、提高认知处理水平,丰富听力学习设计、建构多元化图式等方面必将起到积极的推动作用。
媒体点播 篇2
计算机科学与技术系
课程设计任务书
2016～2017学年第二学期
课专指业导班教
程 级
师
Web应用系统开发 视频教学点播系统 课程设计名称
2016年12月
课程设计目的
通过课程设计，学生在下述各方面的能力应该得到锻炼：
（1）进一步巩固、加深学生所学专业课程《Web应用系统开发》的基本理论知识，理论联系实际，进一步培养学生综合分析问题，解决问题的能力。
（2）全面考核学生所掌握的基本理论知识及其实际业务能力，从而达到提高学生素质的最终目的。
（3）利用所学知识，开发小型应用系统，掌握运用Web应用技术编写调试应用系统程序，训练独立开发应用系统，进行数据处理的综合能力。
（4）对于给定的设计题目，如何进行分析，理清思路，并给出相应的数学模型。
（5）熟练掌握HTML、XML、CSS、JavaScript、JSP、JDBC等相关技术。课程设计名称及内容
课程设计名称：视频教学点播系统的设计与实现
设计内容：实现一个供计算机爱好者交流和培训的平台，实现资源共享，免费培训。任务和要求
任务：根据对实际需求调研,设计并实现一个能基本满足实际需求的软件系统。主要功能包括会员的管理(注册,登录,查询等,排行榜,帮助),视频资料管理(新增,删除,修改,搜索,排序),视频的在线点播,用户资料上载,对上载资料的审核管理,其它辅助功能包括:系统基本资料的设置
要求：系统要求需求分析相对完整,主要功能完备,界面友好 设计方案提示
4.1 系统中的所有数据都应存储在关系数据库中，建议采用MS SQLServer或者MySQL。其它
开发环境要求：Eclipse/MyEclipse + Tomcat 8/7/6
3人题 参考资料
[1] 邹建.深入浅出--SQL SERVER 2005开发、管理与应用实例.人民邮电出版社,2008.[2] 樊月华.Web技术应用基础.清华大学出版社, 2006.[3] 飞思科技产品研发著：JSP应用开发详解（第二版），电子工业出版社, 2004年.[4] 张洪伟著：Tomcat Web开发及整合应用，清华大学出版社, 2006年.[5] 陈刚著：Eclipse从入门到精通(第2版)，清华大学出版社, 2007年.[6] 张建,陈陶.电子资源的在线视频点播系统.现代情报.2007第7学期
[7] 肖克曦,基于ASP.NET 的教学视频点播系统.多媒体技术及其应用.2007第5期 [8] 张淑霞.基于宽带应用的视频点播系统的设计与实现.科技情报开发与经济.2004第5期 [9] 雍全明.一种基于A SP 和ADO 技术的在线点播系统.科技信息.2008年
BT免费在线云点播技巧 篇3
Step1 首先启动IE浏览器到http：//pan.baidu.com/s/1mgsSiAs，点“下载”将WatehTorrents Player下载到硬盘，下载得到的是WatchTorrents Setup.exe这个安装执行文件，如果你用Chrome（下载网址http：//rj.baidu.com/soft/detail/14744.html？ald）去下载，Chrome可能会认定该安装文件属恶意软件，不要管它，选择“保留”继续下载。
Step2 下载完毕，双击WatchTorrents Setup.exe讲行安装，如果弹出安全性警告窗口，点击“执行”继续安装，然后出现WatehTorrents Player欢迎画面（图1）。
Step3 点Next弹出选择安装目录画面，现在要求设置将WatehTorrents Player安装到何处，默认安装目录为C：＼Program Files＼WatehTorrents Player（图2），点Browse按钮可以自行改变安装目录，如果使用默认的安装路径或者安装目录设置完毕，就按Next继续，再点Install进行安装。
Step4 安装过程中会弹出一个提示框提醒你关闭所有的浏览器，此时应该先关闭所有打开的浏览器窗口，然后再点选“确定”（图3），接下来会自动安装浏览器插件，BT播放工具主要是附加在浏览器上供你使用的。
Step5 安装完成后出现这个画面（图4），表示WatchTorrents Player已经安装成功，点击“Finish”按钮退出安装向导，此时浏览器会跳转至http：//watehtorrents.com/？q=thankyou，打开感谢安装WathTorrents Player的网页。
Step6 由于WatchTorrents Player并非以单独的软件，而是作为浏览器的一个插件而存在的，所以安装了WatchTorrents Player后，浏览器就有BT下载和播放功能了。例如你打开IE，点右上角的设置按钮，在弹出的菜单中点“管理加载项”，点“工具栏和扩展”（图5）加载项类型，就会看到一个FrmPlayer Control控件，这就是watchTorrents的外挂程序。
Step7 打开Chrome，点设置按钮，在弹出的菜单中点“工具→扩展程序”，在扩充功能中也能看到一个WatchTorrents的外挂程序（图6），点击勾选“启用”，现在浏览器就具备BT下载和在线播放功能了c
Step8 以后上网打开浏览器，到BT电影网站，找到要看的BT影片并打开其网页，在BT种子链接上右击鼠标就会弹出一个菜单，选择其中的“Play torrent”（图7）即可开启播放程序观看BT影片。
Step9 若BT的种子还存在，用WatehTorrents Player播放时，点窗口左下角的播放清单图标能看到种子清单，通常B吓载文件内并非只有一个影片文件，还会有一堆说明文件、图片或广告等，如果你要选择播放，则点选“+”展开种子内的文件清单（图8），然后双击要播放的影片文件，即可开始将影片载人缓冲区中，此时画面上会有一段下载至缓冲区的等待，主要是避免播放时造成的延迟动作。
Step10 对于基本的BT播放功能，WatehTorrentsPlaye都有，假如BT种子清单内有字幕，还可以用它来切换字幕，该软件嵌入浏览器的播放方式确实很方便，不过实际情况是网上能用的，torrent种子很少、而且BT种子也容易失效（例如现在能用，过几天就不能用了），因此提醒你网上很多BTT载地址都可能无法播放，所以只适合你用它上自己熟悉的BT电影网站！
另外假如你有能用的BT电影种子网址，不仅可以在浏览器中右击种子链接、选择“Play torrent”菜单进行云播放，还可以到以下网址，输入BT电影种子网址在线云播放：
在线云点播http：//www.vodzx.com/
火焰云播http：//www.huoyan.tv/
小二云http：//www.x2yun.com/
一种网络媒体点播项目开发的研究 篇4
随着网络的发展, 使“宽频KTV、影音聊天室、线上电影院、远程教育”等等梦想变成了现实, 然而, 如何开发出一套高效的网络媒体点播系统, 成了企业竞争的关键所在。根据实际项目工程, 结合当前最新开发工具及性能较好的网络媒体传播技术, 对目前流行的这种网络媒体传播和应用进行研究。
2 设计高效的企业级网络媒体点播项目
1992年, Jack W.Reeves写了一篇论文《什么是软件设计》, 答案是“源代码就是设计”!所以开发一个好的项目, 设计是非常关键的
2.1 企业级应用介绍
企业级应用, 就是指企业经营中需要使用的应用程序。又称企业信息系统或者管理信息系统。其主要任务是最大限度的利用现代计算机及网络通讯技术加强企业的信息管理, 通过对企业拥有的人力、物力、财力、设备、技术等资源的调查了解, 建立正确的数据, 加工处理并编制成各种信息资料及时提供给管理人员, 以便进行正确的决策, 不断提高企业的管理水平和经济效益。
2.2 流式传输媒体介绍
目前, 在网络上传输音/视频等多媒体信息有两种解决方案, 即http或ftp下载以及流式传输。http或ftp下载使用标准的http和ftp协议, 但由于多媒体信息个头巨大, 下载一个多媒体文件一般需要几分钟或几小时的时间, 这就造成需要耗费可能比整个视频都要长的时间来完成下载, 而且这些被下载的文件还必须在下载前制作完成, 放在网络服务器上, 最终还是不能观看网上现场直播。
流式传输时, 声音、影像或动画等多媒体信息由流媒体服务器向用户计算机连续、实时传送, 它首先在使用者端的电脑上创建一个缓冲区, 于播放前预先下载一段资料作为缓冲, 用户不必等到整个文件全部下载完毕, 而只需经过几秒或十数秒的启动延时即可进行观看。当多媒体信息在客户机上播放时, 文件的剩余部分将在后台从服务器内继续下载。如果网络连接速度小于播放的多媒体信息需要的速度时, 播放程序就会取用先前建立的一小段缓冲区内的资料, 避免播放的中断, 使得播放品质得以维持。
2.3 设计合理化流程
根据以上分析, 项目选用Windows Media Services作为流式传输服务器, 采用MMS (Microsoft Media Server protocol) , 这是微软的流媒体服务器协议, 利用Windows Media Services SDK对服务器后台进行架构和操作, 提高使用效率和友好用户界面。编程实现方面, 考虑到服务器是主要功能的核心部分, 而客户端只是应用功能, 为了减少客户端日后维护更新的工作, 根据标准WEB建立B/S结构, 采用C#.NET、HTML、Java Script建立ASP.NET服务器网站, 使得客户端通过IIS就能对服务器进行访问和操作等功能, 从而将维护工作的重心放在了服务器部分。
3 实现网络媒体点播的技术
通过网络, 能实时有效地实现远程媒体的点播及访问, 是该项目工程的核心内容, 编码实现的重点也放在了以下几个内容上。
3.1 面向方面编程技术
面向方面编程AOP (Aspect-Oriented Programming) 是1996年Gregor Kiczales在PARC提出的一种新的编程范式。AOP是一种与OOP截然不同的看待应用程序结构的方式, 按照AOP的观念, 系统被分解为方面 (aspect) 而不是对象。一般情况下, OOP能够很好地避免代码重复。但是对于B/S这种结构, OOP将采用每个客户对应一个服务调用模式, 而采用AOP的委派, 使类之间构成了“客户-服务器”关系。客户类代码简单的调用服务器类的方法即可完成众多的功能“委派”。
而且AOP面向方面编程提供了另一种调用模式, 使客户类能够不需要调用代码, 就能够获得所需的功能, 这样完全消除了重复代码。AOP的调用模式, 如果一个类 (客户类) 需要另一个类 (服务器类) 提供的服务, 那么就不需要在客户类中作任何需要服务的声明。而是在服务器类中指定需要将服务提供给哪些客户类。
3.2 基于.Net Framework以及web标准开发
采用.NET Framework及web来开发, 可以使原来需要通过编程语言来做的一些工作转由.NET Framework来完成, 保证所有支持.NET的语言编写的程序都可以使用这些特性, 开发人员可以使用任何支持.NET的语言使用这些功能, 也就是说, 这些功能是语言独立的, 可以保证通过任何支持.NET的语言编写的软件都具有相同的行为, 操作系统可以提供一些.NET Framework不支持的功能, 降低程序之间通信的复杂性和局限性, 这些程序可以是相同语言编写的, 也可以是不同语言编写了。总之, 具有互操作性、公用运行时引擎、语言独立、基础类库调用、简化开发及安全等多个好处。
3.3 Windows Media Services SDK应用开发
Microsoft?Windows Media?是流式传送数字媒体内容的平台。可以使用Windows Media Services软件开发工具包 (SDK) 生成用于Windows Media Services平台的自定义应用程序:创建自定义用户界面以管理Windows Media Services、以编程方式控制运行Windows Media Services的服务器、创建自己的插件以自定义核心服务器功能、动态地创建和管理服务器端播放列表等等。
3.4 项目整合
基于以上几个技术的分析, 首先利用C#.net结合SDK制作调用WMS操作的后台服务器, 生成IWMSPublishing Point Object来对MWS直接访问操作, 然后利用Java Script、Div、CSS、HTML等一系列前台网络语言, 实现方便的前台调用, 利用.Net Framework的多语言调用, 让C#.net实现的功能结合前台服务数据, 生成一系列服务操作动作。
4 项目测试及改进
在完成编码实现功能之后, 测试是十分关键的一项工作, 它能发现项目工程的缺陷, 从而提高项目工程的质量, 为项目的改进和管理提供确切的数据依据。
4.1 项目测试
4.1.1安装测试, 对产品安装过程进行测试, 收集第一关出现的问题以对操作带来不便的地方;4.1.2功能测试, 对实现的各项功能模块反复运作, 测试功能是否正确、有效、统一、互斥等方面;4.1.3压力测试, 采取海量同步测试, 对同一或相关常用功实时同步进行, 检验抗压力度;4.1.4效率测试, 综合功能及压力测试, 检测功能的执行效率和准确性;4.1.5卸载测试, 最后对产品进行卸载, 测试是否完全以及对原来的安全性是否造成影响。
4.2 项目改进
通过产品测试, 以及相关人员讨论, 结合用户试用反馈, 进行项目的改进工作。
a.利用XML实现多国语言支持
一般的网站对于多语言的支持, 通常采用的手段是准备多个语言版本的网站, 而为了减少工作量, 在此采用XML实现多语言支持, 原理就是将网站上的语言用C#和Java Script的变量处理, 需要显示的时候, 通过对XML文件各个相应字段读取显示, 从来实现只需要设置改动XML文件就可以支持多种语言。
b.项目源码保护
对发布的ASP.NET源代码进行加密保护, 所以分离出前台后台代码, 后台源码编译成DLL文件进行发布, 从而有效保护源码, 前台代码, 即Java Script和HTML编写的源码, 一般都是采用加密成乱码的形式再发布。
结束语
通过这次网络视频点播系统的设计、研发、测试到发布, 采用了B/S结构, 着重对服务器进行操控, 在运行时, 利用C#.net和Java Script相结合, 配合前台用户交互信息, 后台调用WMS SDK对Windows Media Services进行远程控制, 配置媒体服务器, 客户通过IE浏览器, 通过MMS协议实现在线实时观看媒体。
参考文献
[1]Ikon Technologies Corporation, Complete Video Streaming System, 2001.
[2]Neal Whitten (孙艳春等译) [J].管理软件开发项目 (第二版) , 2005.
媒体点播 篇5
第一招：给一个链接即可点播影音
这种方式可能早已被大家所熟知，用户登录一些在线电影播放站点，通过查看电影点播页面的源代码方式、右键单击网页内置播放器面板，并通过查看当前正在下载缓冲影片的“属性”方式等，是很容易获取在线影片的真实在线点播地址的（如图1）。
获取到在线影片的真实在线点播地址（形式如www.XXXX.com/AA.rmvb或mms://www.XXXX.com/AA.rmvb等）后，用户运行RealPlayer11，在其“文件”菜单中选择“打开”选项，然后将刚才获取到的影片点播地址粘贴到现在弹出的“打开”对话框中，最后在这个对话框下方单击“确定”，则RealPlayer11就可以即时播放在线影片了（如图2、图3）。
与使用在线影片点播站点内置的播放器不同，使用RealPlayer11播放在线影片，可以拥有更加强大的播放控制功能，如可以全屏播放、按照特定制式窗口播放、快进播放及即时调节播放画面等。
点击阅读更多学院相关文章>>
分享到第二招：下载中的视频也能点播
网上各类影视资源众多，许多朋友会习惯于使用下载工具（如：迅雷、快车）下载电影或电视剧，但是有时辛辛苦苦将电影或电视剧下载完，却发现当前下载的影视节目并不怎么好看，或者这种影视节目自己以前看过。其实，我们可以借助RealPlayer11，对下载工具中正在下载的电影或电视剧进行提前内容预览，实现“边下载边观看”。
首先要做一个准备工作，为了影片能够正常使用RealPlayer11播放，用户需要关联所有相关的影片格式，如不确定，用户可以在RealPlayer11“首选项”对话框的“媒体类型”选项卡中手工进行关联，
之后下载影片，下载工具以迅雷为例，用户使用常规方式将影视文件导入到迅雷中进行下载，接下来用户将迅雷界面切换到“正在下载”的任务列表，待影视文件的下载进度达到10%左右，用户使用鼠标右键单击下载任务列表中的那个影视文件，在右键菜单中选择“播放”选项，启动播放预览功能（如图4）。
之后，RealPlayer11会立即自动启动，进入影片播放状态。
点击阅读更多学院相关文章>>
分享到第三招：播客网视频也可下载点播
现在许多热门播客网站的确很流行，但是其有的内置视频播放器真的不咋滴。于是有的朋友会希望将播客网站的点播视频，导入到RealPlayer11中进行播放。
首先用户可以在RealPlayer11中直接下载播客视频：用户首先需要将打开的“首选项”对话框切换到“下载和录制”选项卡，选中其中的“启用Web下载和录制”选项，然后退出RealPlayer11（如图5）。
接下来用户打开自己喜欢的播客网站并进入自己感兴趣的播客视频点播页面，将鼠标指针移动到点播视频的播放器区域，RealPlayer11会自动显示一个“下载此视频”的浮动标签，用户点击这个浮动标签，RealPlayer11就会立即启动，当前播客视频会被自动载入并自动进行下载。待下载完毕后，RealPlayer11会自动播放该已经完成下载的播客视频（如图6）。
由以上可以看出，RealPlayer11的网络影音点播功能丝毫不逊色于任何一款同类影音播放软件，结合软件自身非常强大的播放控制功能，用户在RealPlayer11中可以获得更加疯狂的网络影音点播体验！
RealPlayer下载地址：download.enet.com.cn/html/050432004081801.html
上一页 12 3
点击阅读更多学院相关文章>>
论有线电视视频点播技术 篇6
【关键词】视频点播；模式；应用
【中图分类号】TN948.64 【文献标识码】A 【文章编号】1672—5158（2012）08-0065-02
随着娱乐业的不断发展，视频点播技术在20世纪90年代末得到了推广。该技术对电视通信、计算机等技术进行了综合，在视频技术与网络基础的運用中，对传统节目收看的被动方式进行了转变，促使了节目的任意播放和按需收看的有效实现，且文字、声音、静态图片、动态图像等信息融为一体，为用户提供了交互、实时的视频点播服务。
一、视频点播系统的组成
（一）前端系统
1 视频服务器
视频服务器中，存在着丰富的压缩节目，借助网络的帮助，对用户进行服务，同时也可利用MPEG编码器对实况进行实时的转播。通过视频库管理软件模块，视频服务器能够对各项工作进行协调，且对友好的用户界面进行提供。视频服务器具备强有力的存储、I/O以及数据处理能力，其采用时间片调度算法，配置有SCSI硬盘，形成RAID磁盘阵列，且有两块并发码流输出卡配置在视频服务器中，工作方式为热备份。
2 播控服务器
播控服务器对SI统一生成，通过EPG电子节目指南，促使视频服务器播发控制、数字电视功能的完成。播控同时对上行请求进行接收，并通过解释，促使控制上行信息的传递、信息的传播、交互式视频节目的点播等功能的完成。
3 复用器
经MPEG-2压缩编码，音频数据、多路视会产生4—10Mbit/s的基本流数据，之后打包形成PES流数据，最后在TS包中对负载分割后的PES包进行插入，促成单路节目的TS流数据的形成。
4 QAM调制和混合器
经MPEG-2编码复用器，多路节目的TS流复用后，对单路复用TS流数据进行输出，并通过QAM调制方式进行调制。调制QAM后，经混合器对CATV网络上原有模拟电视信号与调制后的信号进行混合，完成CATV的网上传递。
（二）网络传输
传统的CATV以及视频信号等多媒体信号在前端系统上，通过调制和混合后，经过光纤传至各光节点，之后在利用电缆分配网络，使用户进行接收，用户端的控制信号通过反向信道，在处理之后，传达给播控服务器。
（三）用户端系统
通过用户端系统的使用，才能促使服务提供者操作的有效完成。计算机系统中，完成操作的PC终端是带有显示的设备；电视系统中，操作则是由机顶盒与电视机完成的。在用户端系统中，要对硬件问题进行处理，并且还要对相关的软件问题进行处理，只有对客户系统界面进行改造，才能有效实现用户的多媒体交互。另外，实施连续媒体演播时，都要注意声频与视频同步、演播中断与网络中断的协调等问题的处理。
二、有线电视视频点播系统的结构模式
通过对QAM调制器、数字压缩编码器、VOD系统的增设，在数字终端和数模双向传输系统的利用中，促使用户能够方便的通过计算机发出的指令对交互访问进行实施，并对VOD系统视频服务器中的节目源进行点播。用户数字机顶盒对用户指令进行负责，通过下行数字信号解密、解调与压缩编码的回传进行用户收视的提供，对于各种节目播出的控制与收费，VOD系统都能够自动进行。一般来说，视频点播系统的应用模式包括全数字双向传输系统中VOD的应用模式和数模双向传输系统中VOD的应用模式。
（一）数模双向传输系统中VOD的应用模式
数模双向传输系统中VOD的应用模式包括多功能数字机顶盒、双向HFC分配网和总前端数模数据平台。通过计算机将用户点播的上行回传信号指令输出至多功能数字机顶盒，机顶盒中包括了智能卡、解调、编码、上下行信号调制等功能，在机顶盒的输出下，进入5-65MHz上行信道，并传至HFC光节点光收发工作站，之后利用回传光发射机与光纤光缆接入，回传光接收机在前端数模数据平台中完成接收，后经光电转换，通过交换机进行视频服务器的接入，在双向HFC分配网和总前端数模数据平台的使用中，数字信号由视频服务器输出并传送至用户数字终端，使VOD上下行信号的传输得以完成，并促使视频点播的实现。
（二）全数字双向传输公用网络中的VOD应用模式
如果有线电视网络作为双向数字传输公用网络传输系统具备一定的自动化、网络化、数字化时，VOD的应用模式包括全数字机顶盒、双向数字传输公用网络和双向数字前端平台。通过对数字前端平台的信源的数字化采集、非编、录制、存储、检索，对视、音频数字信号进行输出，进入输入端，通过数字前端输入部分的编码、压缩、解调和各类服务器，在中央网络中心处理器进行ATM全数字平台交换以及网管、条件接收、节目选择等的处理，QAM-64调制输出部分后对下行信道的数字信号流进行混合输出，而路由器输出光数字信号流，通过全数字双向传输公用网络达到光收发工作平台，其数字信号流经光电转换输出，而全数字多功能机顶盒对信号的接收由双向FTLA结构的同轴电缆来实现，完成收视。由用户的上行信号和经全数字多功能机顶盒交换输出的数字信号分别通过上行信道，在收发工作平台混合输出后，利用光电转换对全数字ATM平台与数字前端输入部分进行接入。交换～01Yg因特尔网、IP电话、VOD指令、以及数据信号进行交换，各自的服务器分别接收，实现双向数字传输功能的有效发挥。
三、视频点播技术在有线电视网的应用
中国数字有线电视节目的成功首播是在2000年的深圳完成的，而有线电视联网在全国的应用遍布了24个省、自治区，直至2001年完成全国的联网。HFC分配网由同轴电缆升级改造，且升级改造为双向HFC分配网。对于双向HFC分配网的研究，进行综合业务试点的有线电视网络公司目前在全国有300多个，为数字有线电视多功能的开发和推广创造了许多条件。双向HFC网由HFC网改造的过程中，开展视频点播、因特网接入、数据传输、广播电视等综合业务试点的有线电视网络公司非常的多，且在这一方面取得了一定的成功经验。当前，在有线电视网络多功能业务的开展中，数字机顶盒以及视频点播系统的发展非常的迅速，并且在市场上促成了产品的商品化和实用化。
四、结束语
视频点播作为多媒体数字双向自动互传的系统，工作是在计算机主机上进行的，它综合了多媒体计算机、数据库、视频服务器、数字视频压缩编码、数字电视等技术，形成了自动点播交互电视，为用户提供了更为方便的视频收看服务。从某种层次而言，它的运用代表着数字交互式信息和全功能网络化技术的应用和发展，在互动的内容和形式上，表现的更为深层，并且是交互视频新闻/广告和数字影院的发展基础，有着广阔的发展前景。
参考文献
[1]刘元春，基于单向有线电视网络的”交互式”视频点播[J].中国有线电视，2006（3）
基于H.323的多媒体点播系统 篇7
关键词：H.323,多媒体,点播
在过去的几年中, Internet已经变成支持多媒体服务的可见基础设施, 包括单向点播的多媒体内容查找, 实时交互服务如电话或会议。存储的或实时的多媒体服务需要一些新的Internet服务来进行数据传输和控制。研究者已经提出了一些传输实时数据的协议, 但是, 发起并控制多媒体会话的协议并不完善。H.323协议为通过基于IP的网络进行音频、视频和数据通信的应用提供了可遵循的标准。本文在H.323协议的基础上, 设计并实现了通过Internet发起并控制存储的或实时交互的多媒体会话的多媒体点播系统。
1. 系统整体架构
本文实现的多媒体点播系统分为三个部分, 分别为MCU服务器, 资源服务器和数据库服务器。MCU服务器遵循H.323协议, 按照H.323协议传输媒体流和控制指令;资源服务器响应点播终端对其他资源的请求, 将其请求的资源传输给各个终端;数据库服务器存放所有系统数据, 包括用户数据等。终端从数据库服务器获取用户信息以完成访问控制、用户权限控制等功能。三个服务器各司其职, 互不干扰, 有效分散了系统的负载, 同时明确了各自的职责, 方便后期的开发和维护。系统结构如图1所示。
2. 资源层设计
在本系统的设计时, 尽量重用HTTP协议, 以HTTP协议为基础的好处是该系统可以最大程度的利用现有的封装协议, 认证协议, 内容标记和客户端访问控制技术, 另外, 成熟和稳定的服务器, 代理, 防火墙等技术也可以为该系统所用。
资源传输是资源层最主要的功能, 资源层主要将所有资源都转成HTML格式, 并通过HTTP协议完成资源的传输, 这里不再赘述。
3. H.323层设计
H.323层主要负责控制指令和多媒体流的传输, 该层完全基于H.323协议, 采用Openh323协议栈进行初始化、控制指令的传递以及多媒体流的传输, 开发语言为C++。
该层采用集中式多点点播模式, 所有多媒体流都由MCU服务器中转, 所有控制指令也均由MCU服务器接收并处理。终端的H.323层处理点播会话的发起和建立, 媒体流的接收, 控制指令的发送等工作, MCU服务器处理多路媒体流的发送, 控制指令的处理和响应等。
(1) 自定义控制指令系统结构
本系统设计了一套专门用于多媒体点播的控制指令, 分为MCU指令, 点播指令, 中断指令, 令牌指令和MCULIST指令。
MCU指令是MCU服务器特有的指令, 用于向终端传递多媒体节目信息, 标识为MCU。
点播指令是终端特有的指令, 用于向MCU传递用户点播信息, 标识为UNICAST。
中断指令是MCU服务器和终端共有的指令, 用于中断当前的多媒体会话, 标识为BREAKOFF。
令牌指令即TOKEN指令, TOKEN是MCU服务器为每个终端生成的唯一标识, 在本系统中, 均以TOKEN来唯一标识各个终端, 由于此标识只在服务器端生成, 终端无从得知, 因此定义了该指令, MCU服务器使用该指令告知终端其对应的TOKEN, 标识为TOKEN。
MCULIST指令是终端多媒体节目更新指令, 标识为MCULIST。
控制指令的基本结构如表1所示。
源Token标识发送方, ISSIGNAL标识指令类别为控制指令, 指令属性为MCU指令, 点播指令, 中断指令, 令牌指令和MCULIST指令等几种。点播内容在附加信息中。
(2) 点播流程
指令流程如图2所示。首先终端与MCU之间建立H.323连接, 连接建立完成后即开始初始化流程, 在进行所有操作前, 终端必须先获取自己的TOKEN, 因此, 由MCU向终端发送TOKEN指令, 用于告知终端的TOKEN, 随后, MCU向终端发送MCULIST指令, 更新终端的多媒体节目列表, 然后, 终端可以在用户的控制下进行节目点播, 点播的节目通过UNICAST指令传递给MCU, MCU接到UNICAST后将用户请求的多媒体信息通过H.323协议传送给终端。若用户想退出, 则可以发送BREAKOFF指令, MCU服务器收到BREAKOFF指令后会结束多媒体流的传递, 并退出H.323会话。
4. H.323服务器处理流程设计
本系统采用集中多点点播模式, 所有终端均需要与MCU建立连接, 终端通过建立连接与MCU交互控制信息和媒体流。每个终端维护自身的连接, 而MCU则同时维护多个连接。MCU对用户请求的处理时通过对连接的维护实现的。
M C U在初始化之前需要导入存放在指定地点的配置文件, 此配置文件中存放了MCU的所有配置信息, 包括I P地址、监听端口号等等。MCU根据此配置信息初始化整个系统。
由于连接可能随时到来, 故MCU始终运行着一个监听线程, 负责处理所有到来连接, 连接到来时, 系统要先检查连接字符串, 该连接字符串有多种表达形式, 主要信息包括:MCU名/MCU地址, 房间ID, 用户名及密码等。系统首先检查此字符串是否是规定格式, 若不是, 则立即拒绝连接, 检查完格式后, 系统继续检查MCU名或MCU地址, 若该项表示的是自己, 则字符串合法, 对于非法字符串, 系统立即拒绝连接, 否则则建立连接, 系统对于每个已接收的连接都要处理控制信息和媒体流直至系统关闭。
对音视频进行转发对于MCU来说也是比较重要的一部分, MCU服务器音视频传输主要指当接到用户点播请求时, 将用户所请求的多媒体内容 (包含音视频信息) 传送给终端。为了满足系统的实时性要求, 在音视频传送过程中, 为每个终端开辟一块音视频缓冲区, 先将请求的多媒体数据放入缓冲区中, 然后再进行数据传递。
5. 结语
本文在研究了H.323协议基础上, 研究了H.323协议与多媒体点播系统结合的可行性, 给出了H.323协议在多媒体点播系统中的应用实例, 为了降低MCU服务器的负载, 提出了两层框架结构, 并详细阐述了终端及H.323服务器的详细设计方案。系统实现验证了H.323协议应用到多媒体点播系统中的可行性。
参考文献
[1]H.Schulzrinne.“RTP profile for audio and video conferences with minimal control, ”Request for Comments (Proposed Standard) RFC 1890, Internet Engineering Task Force, Jan.1996.
[2]D.E.Eastlake, “Universal payment preamble, ”Internet Draft, Internet Engineering Task Force, Oct.1996.Work in Progress.
媒体点播 篇8
现在传统的校园视频点播服务, 采取的就是以网络中心流媒体服务器群为中心, 向校园网用户提供在线视听服务, 各个用户和与流媒体服务器形成星形拓扑结构, 如下图1所示:
随着校园网用户的不断增加, 加上使用校园点播服务的时间相对集中, 会造成大量校园用户的同时访问。流媒体点播系统中引入了大量的流媒体业务, 流媒体业务数据量较大对带宽要求比较高, 并且校园网用户对流媒体播放服务的连贯性和低时延要求较高。而目前的网络对端到端带宽和QOS (Quality of Service, 服务质量) 难以保证, 一旦校园网用户量和业务量加大, 对现有网络造成的冲击就会比较大, 甚至会使得现有网络难以满足常规业务的开展。流媒体点播系统在实际应用中遇到的问题在传统的网络模型和业务模型中是很难解决的。CDN (Content Delivery Network, 内容分发网络) , 为这些问题提供了一个很好的解决方案。
CDN的工作原理是[1]:当用户访问已经加入CDN服务的网站时, 首先通过DNS重定向技术确定最接近用户的最佳CDN节点, 同时将用户的请求指向该节点。当用户的请求到达指定节点时, CDN的服务器 (节点上的高速缓存) 负责将用户请求的内容提供给用户。
流媒体点播系统中引入CDN技术, 在现有的媒体点播系统网络中增加一层新的网络架构, 形成一种传送内容的新型体系结构, 将流媒体内容分到最接近校园网用户的“边缘”, 使用户可以就近取得所需的内容, 提高访问的相应速度, 其好处具体如下:
1. 将流媒体内容放在靠近用户的流媒体点播服务器上去, 可以将目前尚未解决带宽保证和QoS保证问题的网络距离缩短, 从而可以有效地提高相应速度和服务质量。
2. 将点播业务更合理的在流媒体服务器中间分散, 可以更有效, 合理的分散对单个流媒体服务器的压力。
3. 将大量流媒体内容预先分发到靠近网络用户的地方, 大大缓解大批量用户同时点播时对骨干网的冲击。
4. 可以自动将用户引向距离最近的流媒体服务器上去, 减少用户点播时的时延。
5. 实现了流媒体分发的智能化, 大大减少了管理员的工作量。
(二) 系统的设计
1. 系统的模型结构
基于RealNetWorks流媒体系统的CDN系统网络架构主要分为边缘和中心两部分。边缘主要指分布在各个校区的流媒体缓存服务器, 它们连接在一起就构成了所谓的“边缘网络”。用户点播所用流媒体资源分散存放在这些服务器上。主区的管理服务器即CDN管理中心, 主要负责全局负载均衡, 流媒体资源分发, 各个流媒体缓存服务器的负载状况采集。当用户进入流媒体系统点播影视资源时, 请求将交给CDN管理中心处理。管理中心通过预先定义好的策略, 选择当时网络上距离用户最“近”的服务器, 然后将URL提供给用户, 使得用户能够得到快速的服务。管理中心与分布在各校区的所有服务器保持通信, 并且采集各个服务器的负载状况信息和健康状况信息, 确保将用户的请求分配到可用的服务器上去。同时管理中心还根据用户的访问记录, 根据预先定义好的策略预测或则根据管理员的操作, 在边缘流媒体服务器上进行流媒体内容的分发和删除操作。
模型系统采用集中管理模式, 这样可以很好的解决流媒体资源的合理利用问题, 具有负载均衡性能, 可以在整个系统的负荷增加的同时, 将增加的负荷平分到各个服务器上去。
这样的CDN系统包含:CDN管理平台、负载均衡模块、内容分发模块、代理缓存模块。如图2所示:
(1) CDN管理平台:主要是面向管理员, 主要是为了使管理员对整个CDN系统进行便利的管理, 具有如下功能:分发管理 (可设定自动分发或则进行手动分发操作) 、策略管理 (修改策略因素比率和阀值) 、事物管理 (管理员管理、边缘服务器管理) 。
(2) 负载均衡模块:负载均衡模块包括负载均衡策略的决策点和执行点。用户的请求到达后, 负载均衡模块先访问策略库, 获得执行策略, 然后根据获得的策略再访问信息库, 获得边缘服务器的负载情况, 最终执行策略将用户的请求分配到距离用户最“近”的流媒体服务器上。该模块还进行对各个边缘服务器负载信息进行采集。
(3) 内容分发模块:由内容分发决策模块从信息库中获取用户点播情况和记录, 并从策略库中读取分发策略, 确定要进行分发的流媒体节目以及源服务器和目的服务器, 然后由内容分发的执行模块在流媒体服务器之间进行分发和删除操作, 以确保流媒体资源在各个流媒体服务器之间尽量合理的分布, 也可以由管理员根据实际的情况进行手动的流媒体内容分发和删除。
(4) 策略库:策略库包括负载均衡策略库和内容分发策略库。管理员负责更改维护其中的策略信息, 向内容分发和负载均衡提供策略依据。
(5) 信息库:信息库包括点播记录信息库和点播服务器负载状况信息库, 包括向负载均衡和内容分发提供所需的信息数据。
2. 系统的结构设计
其系统架构如图3所示:
系统主要包括客户端、缓存服务器和初始服务器等6部分。各部分之间的相互关系是:
“1”初始服务器把与自己名称相关联的URL授权给负载均衡系统;
“2”、“3”需发行的内容通过分发系统被分发到远端缓存服务器;
“4”某一客户向初始服务器请求所需要的内容, 其请求被负载均衡系统所处理;
“5”该系统重定向其请求到某个最佳缓存服务器;
“6”缓存服务器定期向管理系统发送信息;
“7”、“8”管理系统则对此信息进行详细统计和总结并作为反馈发送到初始服务器和负载均衡系统。
3. 系统的运行环境
为了降低成本, 以较小的成本来提高系统的性能和效益, 所以系统采用软件的方式来实现。流媒体服务端采用的是REALNETWORKS公司的HelixServer9.0软件, 操作系统均选用FreeBSD 7.0版本, 代理缓存系统采用Squid 2.6版本, 负载均衡系统采用Bind 9.3.2版本。客户端运行环境为Windows XP系统, 播放器采用的是RealPlayer 10.0版本。
(三) 系统主要模块功能的实现
1. 系统负载均衡功能的实现
通过软件方式实现负载均衡详细过程如下:
采用的操作系统是FreeBSD 7.0, DNS软件采用Bind9.4.2, 结合了Bind中的“view”和DNS轮询 (round robin) 功能。所谓“view”简单说就是对不同来源的DNS查询请求返回不同的IP, 而这些不同的IP对应着不同的缓存服务器, 从而达到均衡或者说是分担源服务器压力的效果。而DNS轮询可以将多个Session分散到不同的IP上去减轻单台服务器的链接压力。
FreeBSD系统是最小化安装, Bind选择用ports方式默认安装, 下面是几个关键配置文件:
2. 系统代理缓存模块的实现
代理缓存模块由Squid软件来实现。Squid是一个缓存Internet数据的一个软件, 它接收用户的点播申请, 并自动处理所下载的数据。也就是说, 当一个用户要点播一个流媒体文件时, 用户向Squid发出一个申请, 然后Squid连接所申请网站并请求该流媒体文件, 接着把该流媒体文件传给用户同时保留一个备份, 当别的用户申请同样的文件时, Squid把保存的备份立即传给用户, 使用户觉得速度相当快。这里用到的就是squid作为反向代理的功能。
什么是反向代理呢?其实, 反向代理也就是通常所说的服务器加速, 它是一种通过在繁忙的流媒体点播服务器和Internet之间增加一个高速的缓冲服务器来降低实际的流媒体点播服务器的负载。典型的结构如下图4所示:
Squid软件安装完成后, 在其配置文件中加入以下两行内容即可实现Squid的反向代理功能:
(四) 流媒体服务器的安装及运行
流媒体服务器我们采用FreeBSD7.0系统, HelixServer采用9.0版本。把HelixUniversalServerAdv9Linux上传至服务器, 进入此目录安装。
在客户端浏览器输入流媒体服务器的IP地址和端口, 输入帐号密码, 即可登录管理界面, 主要的设置是流媒体的挂载点, 重启一次HelixServer后就可以提供视频服务。
(五) 系统测试数据及分析
在测试过程中, 选择两台硬件配置为P4 2.8G CPU, 1G内存、80G硬盘的PC作为流媒体缓存的硬件平台。操作系统为FreeBSD 7.0, 安装经过修改后的Squid软件。而为了方便测试数据, 这里我们采用一台配置比较低的PC作为流媒体服务器:CPU为Pentium III 933MHz, 内存为192M, 普通IDE硬盘。
1. 直接连接流媒体服务器的负载测试
先在一个测试网页中加入RealPlayer插件的代码, 命名为media.html。测试环境为一个有124台计算机数量的计算机实验室, 测试过程如下:
首先在流媒体服务器端命令行输入以下命令:
观察流媒体服务器刚启动时, CPU、内存等的负载情况如下图5:
从上图可以看到CPU和内存都只是使用了百分之零点几。下面我们在计算机实验室的124台电脑上同时打开测试网页:media.html, 观察服务器的负载情况, 结果如下图6:
在我们的测试中, 有24台计算机播放几分钟后停止播放了。我们实验中的流媒体服务器测试机配置是比较低的, 从上面的统计数据可以看到, 在先不考虑网络结构、网络线路带来的影响情况下, 这个配置支持约100台客户端的直接连接是可以保证流畅观看的。
2. 加入缓存服务器后的流媒体系统效果及测试
把两台缓存服务器加入到此系统开始测试, 在测试过程中我们看到124台计算机中只有3台在播放了一段时间后是停止播放的, 其他都正常流畅播放。此时流媒体服务器的负载情况比增加缓存服务器前好得多, 如下图7:
下面用表1对缓存服务器增加前后作一个对比:
(六) 总结及技术展望
本文针对RealNetWorks的流媒体服务器进行CDN技术的改造, 主要从CDN网络的总体结构入手, 提出了适用于流媒体系统的缓存代理策略与负载均衡策略, 设计了基于CDN的Helix流媒体服务器系统, 并在实际网络环境进行了测试, 测试结果证明了CDN系统有助于流媒体的传输, 在点播的应用环境中, CDN是其中一个重要的组成部分。
本系统达到了预期的目的, 但是仍有许多不足之处, 具体如下:
1. 因为HelixServer的源码不开放, 不能进行更为深入的研究分析;
2. 本系统是在小规模型的基础上建立的, 理论上在建立全球性质的流媒体服务器模型上也是可以的, 但是在内容管理方面有待进一步的发展。
另外由于作者水平以及时间的关系, 目前系统还只在小范围的网络环境下进行了功能测试, 测试所使用的客户端数量还有限, 所以系统中必然还有一些问题没有暴露出来。希望系统能够在实际的应用过程中得到不断的改进和完善。
摘要：首先构建了一套基于CDN的流媒体点播系统平台, 包括了总体设计的模型图、系统管理平台、系统负载均衡、系统内容分发、系统代理缓存等, 并详细论述了实现过程。然后在一个实际的网络环境中测试了这个系统的运行效果, 对比加入CDN前后的流媒体点播系统的性能, 包括系统CPU负载情况、系统链接数、内存占有率等参数, 得出以下结论:CDN系统有助于流媒体的传输, 在点播的应用环境中, CDN是其中一个重要的组成部分。
关键词：流媒体,CDN,负载均衡
参考文献
[1]曹毅, 贺卫红.CDN网络关键技术研究[J].现代计算机, 2004, (4) :39-41.
[2]秦安亮.基于CDN的流媒体服务研究与实现[D].郑州大学:计算机应用, 2007.
[3]马明霞, 张学军.CDN技术及其在图书馆局域网中的应用[J].现代图书情报技术, 2004, (4) :13-15.
[4]覃少华, 李子木, 蔡青松, 胡建平.A novel delivery strategy for streaming media based on proxy caching[J].Computer Engineering, 2005, Vol.31No.2:39-61.
媒体点播 篇9
1流媒体技术
1.1面向流化传输的可扩展视频编码
从编码的角度上讲,视频流化的关键在于:压缩码流自身必须具备较强的自适应性和可扩展性,才能适应Internet相对恶劣的网络传输环境。由于网络视频传输要求视频编码能够适应传输带宽的动态变化,研究人员进一步提出了可扩展编码的概念,其目标是开发可在流化过程中简单、灵活、动态的改变码流传输码率的压缩编码方法。
1.2常见的流媒体技术
目前为止,通用的流媒体应用方案主要有下述三种。
1.2.1 Real Media
Real Networks公司所定制的音频视频压缩规范称为Real Media,是目前在Internet上相当流行的跨平台的客户—服务器结构的多媒体应用标准,它采用音频、视频流和同步回放技术来实现在Internet上全带宽的提供最优质的多媒体,同时也能够在Internet上以28.SKbps的传输速率提供立体声和连续视频。
1.2.2 Quiek Time
Apple计算机公司的Quick Time是数字媒体领域事实上的工业标准,可以通过Internet提供实时的信息流、工作流和文件回放功能,它由三个不同部分组成Quick Time电影(Moive)文件格式、Quick Time媒体抽象层以及Quick Time内置媒体服务系统。QuickTime最大的特点是,其本身所具有的包容性使得它成为一个完整的多媒体平台。
1.2.3 Windows Media
Windows Media是Microsoft公司推出的流媒体技术应用解决方案,视频采用WMV-9的编码格式,音频压缩采用Microsoft公司自主开发的Windows Media Audio技术。
总的说来,上述三种流媒体技术之间的差异并不大。在Windows平台上,配置一套Windows Media流媒体应用系统,费用无疑是最低的,并且有Windows支持,系统较容易构架,也十分稳定。我们学校就采用基于windows media流媒体技术的视频点播系统。
1.3流媒体传输方式
流媒体传输方式有以下几种:
1.3.1单播
在客户端与媒体服务器之间需要建立一个单独的数据通道,从一台服务器送出的每个数据包只能传送给一个客户机,这种传送方式称为单播。每个用户必须分别对媒体服务器发送单独的查询,而媒休服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余首先造成服务器沉重的负担,响应需要很长时间,甚至停止播放,管理人员也被迫购买硬件和带宽来保证一定的服务质量。
1.3.2广播
广播指的是用户被动地接收数据流。在广播过程中,客户端接收流,但不能控制流。例如,用户不能暂停、快进或后退该流。广播方式中数据包的单独一个拷贝将发送给网络上的所有用户。使用单播发送时,需要将数据包复制多个拷贝,以多个点对点的方式分别发送到需要它的那些用户,而使用广播方式发送,数据包的单独一个拷贝将发送给网络上的所有用户,而不管用户是否需要。虽然广播能够实现一对多的网络传输,但广播通信有其自身的缺点,其主要缺点有:广播在整个网段上发送时,容易引起网络的阻塞;广播数据不能越过路由器,从而使位于不同网段的机器不能接收到广播消息;作为一种对等通信,它没有权限设置,不利于网络维护,即任何一个局域网内的用户都可以接收广播数据,而发送端并不知道有多少个接收端。综合考虑,网络广播方式并不适合传输流媒体,因为在远程监控中,不仅需要在局域网内传输,而且要在广域网内传输;同时还需要考虑数据的安全性,而且容易引起网络的阻塞。
1.3.3组播
IP组播技术构建一种具有组播能力的网络,允许路由器一次将数据包复制到多个通道上。采用组播方式,单台服务器能够对几十万台客户机同时发送连续数据流而无延时。媒体服务器只需要发送一个信息包,而不是多个;所有发出请求的客户端共享同一信息包。信息可以发送到任意地址的客户机,减少网络上传输的信息包的总量。网络利用效率大大提高,成本大为下降。
总之,组播吸收了上述两种发送方式的长处,克服了上述两种发送方式的弱点,将数据包的单独一个拷贝发送给需要的那些客户,组播不会复制数据包的多个拷贝传输到网络上,也不会将数据包发送给不需要它的那些客户,保证了网络上多媒体应用占用网络的最小带宽。
2视频点播系统
2.1视频点播系统的组成
学校视频点播系统一般由三个部分组成:前端系统、网络系统和用户系统。
1)前端系统:前端系统一般由视频服务器、各种档案管理服务器以及控制网络部分的设备组成。用于存储、管理数据信息和用户信息,处理用户的交互命令信息,发送用户请求的视频数据。
2)网络系统:主干网络和本地网络。影响连续媒体网络服务系统性能的关键部分。主干网络要求有较高的宽带,用来连接前端系统;本地网络是主干网络的下一级网络,把信息传递给客户端。
3)客户端系统:用户端由带有显示设备pc终端组成。视频点播系统基于网络,完成视频数据的播放,提供用户操作界面,完成最终操作点播。
2.2视频点播原理
客户端向视频服务器发送请求,视频服务器受到客户请求,其中的调度器根据特定的调度方案决定何时在哪一信道上发送视频数据信息,并将这一信息回传给客户端。
2.3流媒体技术在视频点播系统的应用
流媒体技术在VOD中的应用视频会议技术和流媒体技术相结合产生的视频点播技术使人足不出户就能选择想看的电影,感兴趣的节目,甚至是学习课程。视频点播是计算机技术,网络技术和多媒体技术相结合的产物,是一项全新的服务。视频点播技术已经不是什么新鲜的概念了。随着计算机的发展,流媒体技术逐渐应用于局域网此时的技术趋于完善,但有一个困难阻碍了技术的发展,那就是音视频数据量庞大。这样服务器端不仅需要大量的存储系统,同时数据传输的负荷也很大,导致服务器无法进行大规模的点播,随着流媒体技术的出现,在视频点播方面我们可以放弃局域网而使用来实现了。由于流媒体经过了特殊的压缩编码,使得它很适合在互联网上传输。客户端采用浏览器方式进行点播,基本无需维护。
3视频点播系统在党校教学中的应用实例
现在多媒体技术的飞速发展,借助局域网的高速宽带,进行实时的视频及音频的稳定传输,党校学员利用视频点播系统进行远程教学,提供在线教育(课程),专家讲座,名师课程等服务,学员可以自己决定上课时间和学习内容。
然而在Internet上的流媒体远程教学系统从功能上分为两种形式:课件点播系统和同步广播授课系统。
1)课件点播系统。把教师授课的音、视频信息事先数字化,转换为流式视/音频文件存储在流媒体服务器中。但是这个与一般用途的VOD不同是:
课件点播不仅需要播放视/音频,而且还需要同步播放与其相关的文本、图表、动画等,这些图文信息一般存储在Web服务器中以网页文件的形式呈现出来。
在客户端只需要一个Web浏览器和支持流媒体播放的插件,通过网页中的超级连接访问授课站点,再点播相应的课程,视/音频与其相对应文字和图表将在浏览器中同步播出。用户可以对播放的内容进行暂停、重播等多种交互控制。
2)同步广播授课系统。基于流媒体的同步广播授课不需要事先存储流媒体文件,而是将视/音频数字化后直接广播,在客户端的Web浏览器上或流媒体播放器上直接收看,即Internet上的视/音频的实时广播。
4结束语
随着现代信息技术的不断推广,在教学过程中通过视频点播系统,使学员能够通过课件点播进行学习,从而提高了学习效率,从以往都是将所有的视音频节目下载完再播放,视频点播系统利用了尤其是流媒体的实时性和交互性节省了下载的时间和空间。是以往任何视音频媒体无法比拟的。
摘要：随着计算机技术、网络技术和视频处理技术的飞速发展,流媒体技术广泛地应用到视频点播系统中。该文介绍了流媒体技术及流媒体技术在视频点播系统的应用,并介绍了视频点播系统在党校教学中的应用。
关键词：流媒体,视频点播系统,党校教学
参考文献
[1]通科技中心.网络视频技术及应用标准教程[M].北京:人民邮电出版社,2002.
[2]刘亚杰,窦文华.P2P流媒体:一种新型的流媒体服务体系[J].计算机科学,2004,31(4).
[3]朱洁.多媒体技术教程[M].北京:机械工业出版社,2006
媒体点播 篇10
在视频点播中, 传统的C/S模式很容易造成系统瓶颈;IP组播由于可靠性和拥塞控制的限制难以得到广泛的应用;CDN (Content Delivery Networks, 内容分发网络) 因为高额的费用而难以进行全面推广。在这种情况下, P2P技术与流媒体技术相结合, 具有良好的可扩展性、较高的带宽利用率、较低的服务器带宽开销, 已被广大网络流媒体服务商广泛采用, 解决了传统模式下点播流媒体系统可扩展性差、服务能力有限的问题。
P2P点播流媒体系统对数据的下载有严格的时限和顺序要求。缓存策略和缓存替换算法关系到整个网络负载平衡和节点的QOS保证问题。缓存策略是定义一些规则, 这些规则用于确定是否可以使请求的资源的缓存副本满足请求;存替换算法解决的是如何在缓存区内用新数据对象替换旧数据对象的方法。
本文在分析目前P2P流媒体点播系统的缓存管理策略的基础上, 介绍了缓存媒体流的调度策略、各种缓存控制策略、缓存替换算法, 这些策略和算法能满足大多数P2P流媒体点播系统的需要。
2 缓存策略
2.1 缓存策略的主要内容
缓存策略主要包括三方面: (1) 缓存什么内容; (2) 何时进行缓存; (3) 缓存替换算法。
对于何时进行缓存, 大部分缓存算法使用预取策略来提前将部分磁盘数据放入缓存, 以进一步减少磁盘I/O, 提高缓存命中率。通过记录、分析以往的数据请求模式来预测将来可能被请求到的数据段, 将访问可能性大的数据段放入缓存。
2.2 缓存策略的数据分割
2.2.1 首部缓存
首部缓存普遍应用于VOD影片文件。首部缓存将影片文件开始的一部分放入缓存以减小点播用户的启动延迟, 对于影片文件其他部分的访问需要直接读取磁盘。
2.2.2 分块缓存
分块缓存通过将影片文件切分成小块, 以块为单位进行缓存操作。分块缓存分为定长分块与变长分块。定长分块将文件切分为大小相同的块, 变长算法是基于影片文件越靠后的部分被访问的概率越低的推断, 将文件按照首尾位置分块, 各块大小按指数递增。
2.2.3 分层编码视频的缓存策略
不论是首部缓存还是分块缓存, 均忽略了影片的流行度或者“热点片段”并不一定总是位于影片的首部这一情况, 另外, 不同影片的热度也会随着时间的变化而变化。而针对分层编码视频的缓存策略, 它可以决定应缓存哪一个节目的哪一层, 才能最小化传输代价。该策略能根据节目的流行度调整缓存状态[2]。
3 缓存媒体流的调度策略
3.1 静态调度
静态调度采用服务器推模式, 是指视频服务器不考虑用户动态行为而按一定策略广播节目数据, 为用户提供固定的服务延迟。典型的静态调度算法包括阶段广播算法、周期广播算法、金字塔算法、Perinutationpyramid算法等。
3.2 动态调度
动态调度算法采用客户拉模式, 是指媒体流的调度首先由用户请求驱动, 视频服务器根据一定调度算法响应用户请求。典型的流媒体动态调度算法包括FCFS算法、客户端缓存算法、批量传送算法、Adaptive Piggybacking算法等。
4 缓存替换算法
缓存替换算法的好坏直接决定了流媒体缓存系统的性能[3]。目前比较成熟算法有:Lim等人[4]的网络传输成本;Wu等人[5]提出指数增长的分段策略能够快速替换片段来适应缓存对象的访问模式的变化;LRU-K和LCB-K[6]考虑了对象最近K次被引用的信息, 将访问频率和访问的最近性综合到价值函数的设计之中, 具有较好的性能。LRU和LFU算法就是分别考虑访问近期性和访问频率的实现方式, 但LFU存在缓存污染问题, LRU存在长环模式问题, 而且这两种算法还容易出现持续替换同一媒体对象的问题, 导致文件缓存内容被完全释放的概率增大, 请求命中率下降和响应延迟增加。Interval Caching策略提出了NIC算法、PSIC算法、STP-L算法。此外, 还有ATCB-SCU算法、MACCR算法、SCU-K算法[7]等。这些算法都从不同程度上提高了缓存空间利用率和字节命中率, 但是考虑的因素比较单一。
5 结语
P2P流媒体点播系统具有实时性、高效性和稳定性等特点, 随着P2P流媒体技术的日渐成熟, 基于P2P流媒体的应用越来越普及。Internet的迅猛发展和普及为P2P流媒体业务的发展提供了强大的市场动力[8]。本文所介绍的流媒体点播系统的缓存策略和缓存替换算法能够满足大多数用户的要求, 但是每个替换算法的设计都很单一, 仍然存在不足和需要改进的地方。随着视频点播系统未来的发展, 综合考虑节目流行度、缓存字节有效性、文件使用频率、用户访问到达率等因素的高效流媒体技术也将迅速发展并日趋完善。
摘要：笔者在分析目前P2P流媒体点播系统的缓存管理策略的基础上, 对其缓存管理机制进行分析和研究, 针对P2P流媒体点播系统, 介绍了缓存媒体流的调度策略以及各种缓存控制策略、缓存替换算法, 这些策略和算法能满足大多数P2P流媒体点播系统的需要。最后对其应用前景进行了分析。
关键词：P2P,流媒体点播,缓存管理策略,缓存替换算法
参考文献
[1]李谦, 秦亮曦.流媒体传输技术综述[J].微型机与应用, 2015 (8) :4-6.
[2]孟彩霞, 叶海琴.Web缓存替换算法综述[J].福建电脑, 2009 (9) :34.
[3]王小燕.一种高效的流媒体代理缓存替换算法[J].计算机工程, 2009 (14) :72-74.
[4]EJ Lim, SH Park, HO Hong, et al.A Proxy Caching Scheme For Continuous Media Streams on The Internet[C]//The 15th International Conference on Information Networking.2001:720-725.
[5]Wuk, YuPs, Wolf J.Segment Based Proxy Caching of Multimedia Streams[C]//Proceedings of WWW.2001:56-60.
[6]X Yao, J Wang.Toward Effective NIC Caching:A Hierarchical Data Cache Achitecture For ISCSI Storage Servers[C]//International Conference on Parallel Processing.2005:492-499.
[7]LP Zhu, LI Qin, YL Liu.Minimal Access Cost Cache Replacement Algorithm[J].Journal of Daqing Petroleum College, 2006, 30 (6) :73-75.
媒体点播 篇11
近日，派拉蒙影业透露，要缩短电影影院放映与点播的“窗口期”。按照计划，公司将拿两部定档秋季的低成本类型片“试水”：10月23日上映的《鬼影实录5：鬼次元》（Paranormal Activity： The Ghost Dimension）和10月30日上映的《僵尸末日的童子军指南》（Scout's Guide to the Zombie Apocalypse）。目前，派拉蒙已经与美国连锁巨头AMC电影院和加拿大最大的影院经营商Cineplex达成协议，这两部电影将在影院放映结束（即上映屏幕数少于300块）后第17天，提供在线点播服务，这比此类电影的传统“窗口期”减少了1个多月。
事实上，派拉蒙这一计划最令人关注的并非计划本身，而是影院方面对于这一计划的反应。过去几年里，影院方面对于电影公司缩短“窗口期”的呼声甚至做法一直坚决反对。2011年4月，几家好莱坞大公司在电影上映两个月后提供电影点播服务的行为，就曾引起过一场电影公司与电影院线的“大战”，不但有院线发起罢映好莱坞大片的号召，还有包括詹姆斯·卡梅隆、彼得·杰克逊在内的23位业内人士联名抗议，最终以电影公司服软，取消服务收场。
时至今日，派拉蒙谈下AMC和Cineplex的这一结果，可以说向前迈了一大步，雖然只是两部小成本影片，虽然目前只谈下了两家连锁院线，但考虑到美国电影院上座率近年不断下降的现实，和派拉蒙开出的愿意跟电影院分成点播等渠道收入的条件，全面缩减“窗口期”的前景似乎明朗了许多。
与此同时，美国电影院线商联合会（National Association of Theater Owners）也给出了积极表态，联合会副主席帕特里克·科尔柯南（Patrick Corcoran）说：“过去几年，我们一直要求电影公司与院线共同商讨，如何在开创扩大市场新模式的同时，保护影院的‘窗口期’。这次派拉蒙先主动找到院线进行讨论，让我们很欣慰。至于这次‘试水’的结果如何，还要院线认可。”
当然，也有不少分析师认为，派拉蒙之所以能谈下两家连锁院线，与选择类型片“试水”也有很大关系。电影公司一直认为，类型片“保持期”偏短，过长的“窗口期”让电影公司在推出点播服务时又不得不再次破费做宣传。反过来说，对于热门的商业片，院线方面恐怕很难在“窗口期”上松口，派拉蒙副总裁罗伯·摩尔（Rob Moore）强调，公司下一部大制作——预计7月31日上映的《碟中谍5：神秘国度》（Mission： Impossible — Rogue Nation），将不会继续“试水”也是同样的原因。
媒体点播 篇12
关键词：流媒体服务器,安卓播放器,视频点播,视频压缩
全球每天有超过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.