office在线协同

office在线协同（精选5篇）

篇1：office在线协同

细看Office 2007协同工作和信息共享

随着Office 2007的面市，微软将协同工作又提升到了一个新的高度。然而，为了能够完全地发挥这套新的Office的协同工作潜力，Office 2007必须与Office SharePoint Server 2007结合在一起使用。

eWEEK实验室的测试证明了用户们都从Office 2007的协同能力中得到了工作效率的提升，但其中仍有一些障碍，IT经理需要帮助用户越过这些障碍，通过联合使用Office 2007的应用程序和Office SharePoint Server 2007以充分地获得这些协同工作的特性。

从最基础的层面来说，Office SharePoint Server 2007为用户提供了一个用来存储和共享内容的地方，它能够通过预包装的文档工作流程来提高等级。在测试中，我们可以在一个文件夹中设置工作流程，接着邀请用户参与到一个工作流程中来，设置期限和分配任务。

SharePoint Server 2007为用户提供了一个用来存储和共享内容的地方

Office SharePoint Server 2007包括了四个基本的工作流程进程：文档许可、反馈收集、签名收集和处置许可。我们希望工作流程能够以有条件的准则进行，例如当一个文档被更改时。

当一个如Word文档这样的文档在Office SharePoint Server 2007上被共享或提交到一个SharePoint工作流程中时，在这个文档中的Office按钮将会包含了与SharePoint中管理约束条件相连的工具。

例如，当我们打开一个提交到SharePoint工作流程中的Word文档，Word中的ribbon下就会显示出一个标题，提醒我们注意这个事件。当操作这个Word文档时，我们可以直接从Office按钮的“服务器”（Server）或“工作流程”（Workflow）菜单项目中测试这个文档或开始一个工作流程步骤。

我们也发现，就在Word本身的应用程序中，它就能很好地展示工作流程的可选项目。当我们想对一个任务采取进一步行动时，Word呈现给我们一个表格，让我们能够再分配这个任务或要求对文档作出修改以及改变随后的期限。

确实，微软在改进任务管理上是投入了大量的精力，以确保用户在一个SharePoint服务器中也能够看到他们的任务，与在大多数人用于任务管理的应用程序Outlook中所看到的一样。

用于Office协同的Outlook

通过Office Outlook 2007，用户们能够从其它的Office应用程序中导入他们的任务，以获得一致的查看。

这是一个重大的改进，因为任务对象在其它Office应用程序中的增长情况对用户们来说一直是一个难题。Office Outlook 2007能够对Office SharePoint Server 2007、Access 2007、Project 2007和OneNote 2007中的任务实现同步。

Outlook 2007能够从其它的Office应用程序中导入任务

对OneNote中任务的同步让我们能够使用OneNote来直接对任务记录会议议程或改变活动项目。Outlook将这些任务导入到To－Do清单中。当用户对这些Outlook中的任务做上记号以示完成时，在OneNote中同样的任务也会同样被标注以示完成。只要一个任务在Outlook中是可行的，它就能通过标准的Outlook任务管理工具来进行管理。

Outlook还增添了一些其它一般的协同工作的东西，包括能够用于管理内在的信息和传统的RSSfeeds的RSS支持。例如，我们能够让一个Office SharePoint Server 2007的RSS feed与一个SharePoint站点上的任务清单的最新变化保持一致。

除了任务管理，Outlook 2007还改进了用于与外部用户共享日历和安排会议的工具。改进了的日程安排表管理特性则需要Exchange Server 2007作为后端的支持。

OneNote的整合OneNote处在大多数用户通常习惯于Office套件中的边缘地位，不过这也许在Office 2007中能够得到改变：在这个新的套件中，OneNote在任务管理之外，与Outlook和SharePoint整合还有一些实用之处。

在所作的改进中最主要的之一就是与Outlook日历的整合，这在上文已经提到过了。Office OneNote 2007安装了一个工具条项目（在Outlook 2003或2007中），这使得我们能够从一个邀请中获得会议信息——例如时间、参加者以及议程，还可以在一个表格中进行组织，其中还包含一个能够回到Outlook日历中的日历的链接。

OneNote包含了两个新特性，简化了对数据的协同和共享，能够超脱于通过Windows SharePoint Services才可行的限制。通过此项对OneNote的解放，我们就能够编辑一组的页面并通过创建Notebooks将它们共享。我们能够从本地的拷贝、存储在网络分区中的拷贝或是从一个Office SharePoint Server的站点中共享到这些Notebooks。

在我们的测试中，共享一个Notebook被证明是相对比较容易的——我们所需要做的所有事情就是指定共享的位置，无论是本地的或是在一个服务器上，接着OneNote创建一封包含着这个共享的Notebook的链接的电子邮件信息就会分发到其他的用户那里。

这个特性也能够用来在多个计算机上同步Notebook的拷贝。当共享一份本地拷贝时，我们则需要确保我们对接收者给予了适当的权限，在我们用于测试的Windows XP桌面上，一个任务是会要求管理员的权限的。通过Office SharePoint Server 2007，我们能够创建一个特定的OneNote文档库用来管理这些共享的文件夹。

这种共享方法并非完全天衣无缝。OneNote有一个同步化的菜单项，用户必须使用它来复制不同版本之间的更改。此外，OneNote没有用来裁定这些更改的机制，这样就使得大多数最近的改变将会重叠地写在文档中任何较早的更改中。当用户对Notebook的内容进行编辑时，OneNote不断地对一个Notebook写入，这样就会导致问题的出现。我们是能够缓和这些问题的——即使并不是很方便——我们在编辑一个Notebook时将其置于脱机状态，等到完成之后再将其进行同步就可以了。

深入看看Groove 2007

Office 2007表现出了微软将目标放在了Groove上的第一个良机，它在2005年3月，通过对Groove的同名公司的收购获得了它。对Groove所做的改变是有些戏剧化，但这个版

本在Office的世界中还是表现得不错，特别是当它与SharePoint Server、Windows

SharePoint Services和InfoPath

放在一起考虑的时候。

微软对Groove所做的改变是有些戏剧化

尽管如此，Groove 2007在Office套件中还是显得有些零散化，至少在主题方面。尽管使用这个应用程序的协同工作都是与SharePoint Server或Windows SharePoint

Services一起的，但Groove创建的专注于内部的协同则由于P2P网络而孤立。在企业的环境下，对文档控制有着严格的要求，Groove 2007则可能导致一些风险，尽管能够通过将Groove的通讯基础设施置于防火墙中来处理。

Groove 2007的核心特性就是Groove的P2P网络，无论是通过一套微软运行的公共的服务器还是公司向微软购买而在内部运行的服务器，它都能应付得了。用户创建自己的使用模版了的应用程序，并将这些应用程序与其他用户共享，无论是在本地网络或是整个互联网上。共享应用程序的用户是需要通过Groove公共目录的验证的，这个目录是一个在本地网络上发布的服务。用户还能够通过电子邮件或在多台计算机之间（例如一台办公室的计算机与一台家里的计算机）来共享应用程序。

微软已经减少了Groove中可用的模版数目，取而代之的是专注于模版所能交付的核心能力。

这些核心模版目前包括讨论、文件共享、表格、日历、笔记本和会议应用程序。这些应用程序其中有些看起来有些多余——例如，共享的日历对大多数Office用户来说都没有什么意义，因为通过Outlook和Exchange Server来共享日历要相对更为简单。

然而，Groove中很优秀的一样东西是，它能够让组织外的用户更容易访问到那些通常会内在地面向系统的东西，以便参与到基于项目的工作中。Exchange仅能够在一个组织中允许用户共享日历，Groove就能够让一个日历与项目之外的顾问进行共享。除此之外，Groove还包括了一个表格应用程序，用于收集和共享简单数据库信息，例如一个事件的在场者或一个产品目录的详情。

Groove 2007添加了对InfoPath的表格的支持，允许用户能够重复使用他们为内部进程创建的表格。我们并没有发现对InfoPath的支持确实联通实现，尽管如此，公司将很可能需要做一些表格编辑工作来证明Groove 2007的能力。

另一个有趣的特性是对for Office SharePoint Server文档库的支持。Groove的用户现在能够使用Groove客户端，脱机编辑SharePoint的文档。这也让公司能够将合作伙伴引入到这个文档的创作以及进程的编辑中，而不需要从对外地揭露一个SharePoint站点或允许合作伙伴进入到这个网络。一个雇员能够通过有防火墙的保护状态来访问SharePoint的内容接着再将它共享，就像是一种代理权，与外部的用户一同工作在Groove的网络上。这也是一种能让用户在家里的计算机上使SharaPoint内容可用的方法。

IT管理者会为图安全而不希望让这种共享方式发生，但看看Groove作为一个协同工具所具有的价值吧——它能够牢牢地把握住Groove网络。微软还发布了Groove Enterprise Management Server 2007和Enterprise Relay Server 2007，面向想要运行和管理内部Groove网络的公司。Groove 2007能够在安装的过程中进行设置，让它仅通过一个企业桢中继服务器进行连接。

Groove 2007将在微软的Office Enterprise 2007和Office Ultimate 2007两个Office版本的套件中被收入，这也就意味着微软正在错失机会去帮助那些没有IT部门协助的中小型企业迅速建立协同工作空间。当然，Groove也作为一个单独的产品，对每位用户以229美元的标价出售。

篇2：office在线协同

其实，在Office套装大红大紫的同时，它还有个不知名的小师弟：Works。多年来，微软Works就像是软件界里的丑小鸭，但在新形势的发展下，Works摇身变成白天鹅也并非没有可能。Windows Live、Office Live的极力推广就显现了微软对在线服务的重视，而基于Work的在线版Office也正在向我们走来。微软信息员工办公策略主管Alan Yates在与路透社的谈话中表示：我们也正在考虑如何利用一些新的商业模式，如广告支付模式、新的发行模式等，

说起Office办公，微软的经验自然是Google无法比拟的，不过Google服务也有着自己的特定用户群。Google Writley和Spreadsheets虽然过于简化，与微软Office相比根本不在一个层次，但如果用户只是简单地编辑文字，Google的服务已经足以应付，而且还有一个天然优势：在线共享与协作。微软Office也有着优秀的协作系统，但仅限本地，且交流不便，Google则引入了实时互联网通讯。

篇3：面向在线协同制作的门户系统设计

关键词：协同制作,视频转码,反向代理,门户系统

0 引言

传统的基于桌面应用程序的节目制作软件,往往受限于产品对用户计算机性能的要求,并且操作和功能设置过于复杂,无形中增加了与使用者之间的距离。将传统的节目制作软件用网络的形式呈现并且提供用户协同的功能,本身就是一件激动人心的事情。而在整个基于广域网环境的在线节目协同制作系统中,提供服务的门户系统是决定用户体验的关键因素,搭建一个用户体验好、高可用性、高可扩展性的门户系统至关重要。

将传统的单机节目制作通过Web方式实现,并且实现多用户之间的协同功能,需要门户系统和节目制作系统之间无缝结合,门户系统和后台的节目制作协同服务器之间具有良好的交互策略以及门户系统与集群转码系统之间可行的转码任务管理通道。门户系统还需要能够提供稳定、有效的用户管理、素材文件管理、项目管理等功能。并且,为了使门户系统能够支持多用户和处理高并发情况,在系统架构设计时考虑到可扩展性,采用前端反向代理、静态缓存、服务器集群等技术。

1 系统架构设计

在线协同制作门户系统除了具备视频分享类网站视频上传、预览、评论、分享等基本功能外,用户上传的共享视频都将是在线视频制作的素材,视频的在线协同编辑是该系统的一大特点[1]。系统设计从业务功能、性能要求、易于拓展等方面进行考虑。系统架构包括系统的构成和业务模块设计两个部分。

1.1 系统的构成

门户系统主要由反向代理服务器、内容服务器集群、数据库服务器等构成,如图1所示。

反向代理服务器:主要实现对后端内容服务器的负载均衡、静态文件缓存、页面重定向,以提高用户的访问速度,减轻服务器的压力。

Web内容服务器集群:实现系统的业务功能,完成用户管理、项目管理,与协同管理服务器进行交互,是系统功能实现的核心部分。

数据库服务器:用户信息、海量视频文件信息、项目信息等的保存与管理。

1.2 业务模块设计

按照系统的功能将应用分成业务模块进行实现,主要包括用户管理模块、用户组管理模块、文件管理模块、项目管理模块、消息管理模块等,如图2所示。

反向代理服务模块:实现负载均衡、静态文件缓存等功能。

个人信息管理模块:主要实现用户的登入、登出、注册等操作,同时需要保证session和cookie内容的更新与同步。

文件上传模块:实现调用ActiveX上传插件,实现无大小限制的文件上传。

消息管理模块:实现好友请求处理、组请求处理等消息处理功能。

组管理模块:用户组的创建、查询、添加/删除、解散组等操作。用户组同时也是协同项目的归属者。即为了保护协同项目的可操作性、保密性,同一组内的成员才有权限加入该组的协同项目。

项目管理模块:项目的创建、项目状态查询、项目成员添加、项目发布等功能。

文件下载模块:在Java程序中调用存储系统提供的下载DLL接口,获得文件的下载地址,生成文件的下载URL。

数据库访问模块:向业务层提供数据库读取等操作服务。

2 系统的实现

系统采用J2EE平台[2],配合MySQL数据库[3]以及相关技术实现,按照业务需求分模块实现各部分的功能,并且设计一种能给用户优质用户体验、易于功能拓展的协同制作业务流程。

协同制作作为门户最主要的业务,其涉及到的关键技术主要有:不同格式视频的统一低码率格式转码,以便视频编辑的特效和素材预览;反向代理服务器的搭建,以减轻Web服务器的访问压力,实现可平滑拓展的网络架构。

2.1 反向代理服务器

nginx以其稳定性、高并发性、低系统资源等特性获得越来越多的应用。本系统主要利用nginx做静态文件的缓存、后端Web内容服务器的负载均衡。

利用nginx的静态文件缓存功能,客户端发送过来的请求首先送到反向代理服务器。如果客户请求的内容在反向代理服务器的缓存中存在,就直接返回给用户,不需要再去访问后端的内容服务器。如果客户请求的内容不在缓存中,则将请求进一步送到内容服务器,并将内容服务器返回的结果缓存起来,并进一步送给客户端。

利用nginx的负载均衡功能,能够将多台内容服务器进行集群,同时对外提供服务。用户的访问请求,将由反向代理服务器的调度策略,根据后端各个HTTP服务器的运行状况,做负载均衡处理,决定由后端的哪台内容服务器提供服务。同时,后端的某台用户服务器意外宕机时,反向代理服务器也能进行智能切换,保证服务的稳定、可持续性。

nginx在Linux环境下的安装和配置并不复杂,主要通过一个配置文件来定义各种服务的功能,利用nginx作为高速缓存代理,它具有以下作用:

1)加快对客户的响应时间,减轻后端内容服务器的负载;

2)保障内容服务器的安全;

3)减少内容服务器节点之间占用的网络带宽;

4)对内容服务器进行负载均衡。

2.2 视频转码服务

根据系统需求,系统能够支持MPEG-2,MPEG-4,H.264,DV等格式的视频上传。因此,必须将上传的原始素材统一转化为一种低码率素材,通过流化服务器提供给用户素材预览以及编辑时候的特效、成品预览。系统因此设计了后台对上传的素材文件统一低码率格式转码的功能。

为了降低各个子系统之间的耦合性,将门户系统和后台的集群转码系统分别开来,由门户系统对每个上传的文件发起素材默认转码的任务请求,通过XML交互的方式提交转码任务给转码系统,转码调度系统对任务XML进行解析,将转码任务分发给各个运算节点,目标格式文件生成后,通知门户监控中心,并且将转码任务结果以XML的形式返回,门户通过XML处理系统对各个文件的转码状态进行控制处理。整个视频转码功能的结构如图3所示。

同时,由于集群转码系统的独立性,该系统还将转码单独作为一项供用户使用的业务功能,用户可以上传支持的视频格式文件,通过系统在服务端将视频转换成用户设定的目标格式,再下载。这种工作方式免去了用户安装复杂转码工具的困扰,并且利用服务端强大的集群运算性能,能够大大减少转码所需要的时间,用户付出的代价仅仅是通过Web上传文件和下载目标文件的时间。

2.3 协同制作业务流程设计

协同制作作为门户系统的核心应用,其包括的主要功能有:新建协同项目、用户加入、用户退出、项目保存、项目发布、项目删除等。从Web应用的角度,图4给出协同制作的主要业务流程。

门户系统负责协同制作项目的管理,在用户选择启动某个协同项目时,将项目的ID号和用户ID通过参数方式传给客户端swf进行初始化。并且在接收到成品通知之后,门户系统需要发起后台转码的任务,将成品转码成低码率文件,供用户在网页上预览。

门户系统与协同服务器之间除了通过参数传递进行通信,还通过调用协同服务器开放的Web Service,来协助协同服务器进行项目的管理和成员状态的控制。

3 性能测试

系统在部署上线之前,需要进行功能验证测试、压力测试等,以保证在运行过程中能够满足给定的容量和业务响应时间指标。对门户系统进行性能测试的工具很多,其中Mercucy LoadRunner[4]是专业工具之一,它是一种预测系统行为和性能的负载测试工具,能够以模拟成千上万用户实施并发负载和及时性能监测的方式来确认和查找问题。通过使用LoadRunner,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。

系统在测试过程中,可以通过脚本录制,对整个应用系统处理静态请求、动态请求、数据库处理能力、特定的业务进行负载测试。本文中通过录制用户打开主页面的脚本,对多用户并发请求主页面的场景进行测试。

3.1 测试环境

测试环境中机器设备的配置情况见表1。

LoadRunner中测试场景配置如下:逐步加载1 000个Vuser,每隔15 s添加50个Vuser(虚拟用户),每个Vuser在一次请求页面返回后间隔3～5 s发起下一次请求,并且每次请求浏览器不缓存页面数据,相当于每次请求都是模拟一个新用户重新发起。加载的主页大小为112 kbit。

3.2 测试结果

图5～图7是系统测试的相关结果图。从结果可以看出,系统在完全加压的状态下运行了20 min,系统的最大网络吞吐量达到28 Mbyte/s,每秒请求响应次数峰值达到3 514。对于112 kbit的静态页面请求,平均的响应时间为0.012 s,没有失败的事物数。并且观察到反向代理服务器的CPU占用率稳定在15%左右,由于静态文件在反向代理服务器端有缓存,所以后端的Tomcat应用服务器和数据库服务器在本测试中没有承受压力。

该测试表明在1 000用户并发请求静态页面情况下,系统能够稳定的运行,并且从测试结果来看,系统还能支持更多的并发请求。在实际系统测试过程中,对系统响应静态文件的测试只是一部分。测试方案中,更要重点考虑对动态页面请求、核心业务等进行性能和压力测试,因为动态页面的响应需要经过Tomcat处理并且多数情况下涉及到数据库的操作,很容易成为系统的瓶颈。通过测试找到系统的瓶颈所在,然后优化代码及系统配置,从而提高系统的性能和稳定性。最后,测试方案中还可以通过设定混合场景,按照百分比来模拟不同的用户同时操作不同的业务,模拟系统真实的运营环境。

4 小结

系统在实现过程中,还解决了许多性能优化的问题。例如,对于门户系统中许多需要与数据库进行交互的动态页面,在实际应用中,这些页面不需要很强的实时性,并且对所有用户都具有一致性,采用对这些页面伪静态化的策略,即在服务端模拟HTTP请求生成静态页面并适时更新。用户请求的内容是静态的,这就进一步减轻了后端内容服务器和数据库的压力。

门户系统通过各个模块的协同工作,将协同制作、素材预览、成品发布、文件下载等功能集成一体,具有很广阔的应用前景。系统良好的架构设计,在系统需要增加自身访问容量的时候,只需平滑扩展服务器的数量,就能提升系统的访问容量和并发数。

参考文献

[1]孙思慧,孙军,王兴东.面向在线制作的集群转码系统设计[J].电视技术,2010,34(1):18-21.

[2]刘中兵.开发者突击:Java Web主流框架整合开发[M].北京:电子工业出版社,2008.

[3]唐汉明.深入浅出MySQL数据库开发、优化与管理维护[M].北京:人民邮电出版社,2008.

篇4：office在线协同

用户可以访问微软网站

（http:// /www.microsoft.com/office/preview/beta/testdrive.mspx），在浏览器内测试该软件。这是微软第一次提供这种基于浏览器的Office β测试，支持这种测试的浏览器是IE6以其后的IE版本。

微软已经发布了两个Office 2007 β版，并称已经有250万人次下载了今年5月开始提供的β2。新版Office下载到Windows机器中以后，将取代任何较早版本的Office，即使是测试版也是这样。这可能给系统中已经存储的Office文件带来兼容性问题，因为测试版软件不总是与以前的版本兼容。通过浏览器测试Office 2007，就避免了这个问题。

在线测试Office有可能引起人们的猜测，即微软最终会将该软件作为网络服务在线提供。微软已经提供了名为Office Live的服务，其中包括网站托管、文件管理和企业管理工具，但是微软没有以测试Office 2007这种方式提供办公应用软件。

篇5：面向在线制作的协同制作系统设计

在基于广域网环境的在线节目制作系统中,需要实现在线的节目的协同制作。随着互联网上的视频节目越来越多,网络视频对人们日常生活的影响越来越深。目前,大多数视频网站仍然是以分享为主,如果想对这些视频节目进行编辑制作则显得不是很方便,而且,有时为提高工作效率,人们并不满足于单机的低效率工作模式,而是希望能够多人协同工作,传统的非线性编辑软件并不具备上述功能,这样在线节目协同制作系统就有着重大的作用。

要实现在线的节目的协同制作,需要解决两个重要的问题:一是如何实现在线的节目制作,二是如何实现协同的节目制作。现在已有不少的在线制作成功网站,但是其在线制作功能都相对简单,尤其是素材的预览等待时间太长,用户体验不佳,笔者设计的系统提出了一种新的方法来解决这个问题,与它们相比有了明显的改善。而协同制作,迄今为止,还没发现有人做这方面的工作,是很有研究意义的。

要满足在线制作的需要,就不能采用传统的C/S模式架构,而要转向B/S模式架构。与传统C/S模式不同,B/S模式将客户端统一为浏览器形式,而且还带来了跨平台特性。

为实现协同制作,需要考虑如何来处理组内所有用户的操作,并通过一定的方法来更新组内用户的操作,使得用户能够准确快速地获得组内其他用户的操作,从而达到协同制作的目的。

1 协同制作系统设计

笔者所说的在线制作主要针对的是FLV格式的素材,它是最为常见的互联网上的视频格式。若是需要对其他格式的文件进行制作,则首先需要进行视频转码[1]。

1.1 系统构成

整个系统分为协同制作客户端模块和协同管理服务器模块。协同管理服务器负责管理所有正在进行协同制作的业务组,并提供组内用户间的信息协同,包括开放时间线管理、对象的操作管理等,并向后级系统发送成品生成任务等。协同制作客户端模块主要负责传统的非线性编辑的相关操作,提供用户操作界面、本地素材管理、时间线管理、成品预览等功能。整体系统结构如图1所示。

1.2 系统设计

协同制作客户端采用Flex[2]技术设计,Flex是由Adobe公司推出的创建富互联网应用程序的开发框架,用户只需在本地预装了Adobe公司的Flash Player就可以通过Web浏览器实现在线的节目制作。事实上根据统计,大约98%的个人计算机上都已经装了Flash Player。

客户端和服务器之间采用Socket通过一种叫做AMF3的二进制协议进行通信,它可以高效的实现对象的序列化和反序列化,从而提高传输效率。而若采用传统的Web Service,则数据的冗余将很厉害,因为Web Service是基于XML的。采用AMF3[3]可以节省服务器的带宽,这样就可以有效地提高单位时间内的处理能力。

在该系统中,客户端和服务器交互是非常频繁的。因为Java和Flex能够非常方便地进行数据的交互,一个开源的叫做blazeds的项目中提供了在Java端序列化和反序列化AMF3 Object的库,非常地方便。所以服务器采用的是Java技术开发。

2 协同制作系统实现

上面提到协同制作系统分为协同制作客户端模块和协同管理服务器模块,下面就这两个模块的实现进行具体的介绍。

2.1 客户端实现

协同制作客户端主要目的是提供给用户一个在线的视频节目制作工具,通过具体的UI实现节目的制作,实现了类似于传统的非线性编辑[4,5]软件的功能。包括下面几个模块。

2.1.1 素材管理模块

素材管理模块负责从外部导入素材,以及提供制作所需的相关特效,从而开始时间线上的制作。素材的导入途径现在主要是通过用户上传,录入检索服务器,然后从检索服务器的搜索所得。特效则包括一些基本的轨内和轨间特效,以及一些滤镜,同时也支持字幕,这样制作用户就可以通过它们进行视频的编辑制作。

2.1.2 时间线操作模块

时间线操作模块是制作客户端的核心部分,实现音视频的制作,包括在时间线上添加删除音视频、特效、字幕,并对一些属性进行设置等操作。整个时间线的基本结构如图2所示,包含视频轨、音频轨、字幕轨,在每道轨上是按照时间顺序排列的相应素材。其中视频轨主要是处理视频和图片的相应操作,可以添加轨内轨间特效等,为最后的成品提供视频部分。音频轨主要是处理音频的相关操作,为最后的成品提供音频部分。字幕轨主要是处理字幕的相关操作,为最后的成品提供字幕部分。

整个时间线操作模块的工作任务最主要可以分为:分析并存储用户操作;执行操作。存储操作是为了实现协同,同时还有撤销复制功能。用户在界面上的操作是多样而复杂的,如何对用户在时间线上的各种不同的操作进行分类,是其中最为关键的问题。

在该系统中首先是根据素材类型来进行分类用户操作,即分为视频(图片)、音频、字幕三大类,然后对每种素材又分为添加、删除、改变属性三种基本操作。其他一些比较复杂的操作也可以由之组合得到,比如视频的剪切操作是通过添加两个新的视频和删除原来的视频操作而得到的。移动素材的位置可以由删除素材和添加素材两个操作来得到的。所以说,一个用户操作应该是一个或者多个基本操作构成的。而上面提到的基本操作可以组合实现所有的用户操作。

该系统中,将所有的基本操作存于一个数组中,具有相同任务ID的几个连续的基本操作代表一个用户操作。存储结构如图3所示。

对于每个基本操作,都定义了相应的事件处理函数。所以执行用户操作,则是首先对用户的操作进行分解,分为一个个基本操作,然后执行每个基本操作所对应的处理函数,这样就实现了对一次用户操作的处理。

整个时间线的工作流程如图4所示。

2.1.3 素材预览模块

素材预览模块是供用户在制作的过程中实时的查看最后制作的成品的,是制作客户端的又一个非常重要的模块。用户在制作的过程中,总是需要知道自己制作的成品的效果如何,通过观察对比修改,从而达到自己制作的目的。如何能够快速的使用户看到制作出来的成品效果,是影响到用户体验的一个关键问题。

现在流行的视频制作网站的方法都是将时间线上的音视频等信息立刻传递给后台服务器开始生成成品文件,这种方法有一个很大的弊端。这样若是用户在制作的过程中想查看一下当前的成品的播放效果就不得不临时生成一个成品文件,并等待成品文件生成完毕后进行预览,而这需要等很多的时间,会给用户带来很不好的操作体验。

本系统通过采用Flex框架提供的音视频及一些特效的库,将制作过程中的客户端的成品预览和最终的成品生成分开。因为成品生成是需要耗费大量的时间的,而该系统只在客户端模拟成品的效果,只是需要在播放前将所有音视频连接到流媒体服务器,建立连接之后就可以自由地对音视频文件进行操作,大大减少了等待时间。虽然可能在精确度上有所缺失,但是由于在制作过程中不需要再在后台服务器进行成品文件的生成,用户体验得到了很好的改善,是具有很大先进性的。具体的流程为:整理时间线上的素材信息,首先按照时间对素材进行排列,然后按照下面的方法对轨分段,通过不同的方法来实现相应得功能。音频轨和视频轨的处理方式相同,因为它们的基本结构是类似的。而字幕轨由于没有特效也比较简单,不做更多的介绍。下面以视频轨为例进行分析,一个简单的视频轨信息分段如图5所示。

1)从时间线上的信息得到该视频的播放起始时间和结束时间,从流媒体服务器获取数据并在预览窗口通过FLV播放器进行播放。目前该系统中所采用的流媒体服务器为Flash Media Server。

2)和上面一种情况不同的是,此时除了播放视频,还需要播放特效,采用Flex提供的丰富的特效库来实现,目前支持淡入淡出、飞入飞出、旋转、缩放等多种特效。

3)用定时器延时相应的时间,期间什么都不做,预览窗口应该显示为黑屏。

当每道轨已经按照上面的方法分好段之后,连接好所有的成品预览所需要的音视频素材至流媒体服务器,这样后面用到相应的素材时,不需要再次和流媒体服务器建立连接,否则有可能出现播放过程中不流畅的情况。根据时间轴的信息来检测是否需要播放分段,播放什么分段,并选择相应的处理方式。

图6是该系统所实现的制作客户端预览成品的流程框图。

2.1.4 客户端用户操作同步更新模块

该模块主要是用来实现协同功能,它需要和服务端的更新模块一起工作。其中该模块负责定时将客户端时间线的操作发送至协同管理服务器。协同服务器接收到组内某个用户发送的操作后,将该操作发送给组内的其他用户,通知组内的其他用户更新界面显示,实现协同制作。

2.2 服务端实现

2.2.1 制作组及工程管理模块

制作组管理模块负责制作组的创建、销毁等操作。在该系统中,一个制作组相当于传统的非线性编辑里面的一个工程。但是和以前又有所不同的是,可以由该组的所有成员同时操作这个工程,共同完成制作,这就体现了时间线上的协同制作。所以说,该系统中的制作都是以一个制作组为基本单位进行的,若是组内成员只有一人,表示只是简单的单人制作,若是组内成员有两人或者更多,就意味着多人协作。

同时该模块还负责处理Flash程序的一个非常常见问题,Socket的安全策略问题。即当Socket试图建立连接时,需要被连接服务器的授权,否则会因为没有权限而带来安全沙箱问题,导致无法正确建立连接,系统无法正常工作。

2.2.2 服务端组内用户操作同步模块

该模块真正负责处理组内用户的操作同步,它接收各个组内成员的操作,对操作进行分析,将组内其他用户的操作发送给某个用户,用户接收到后,在客户端时间线上反映出来,实现协同制作,大大的提高了工作效率。

向组内的用户发送更新操作时有下面几个步骤。考虑到效率,服务器并不是每当有新的操作来的时候都更新组内用户的客户端显示。而是每隔一段时间向组内用户发送更新所需的信息来执行更新,起到提高效率的作用。

2.2.3 成品任务管理模块

该模块主要任务接收成品的参数,并向后级系统发送成品生成的任务。客户端的成品预览,只是模拟最终的制作成品的效果,并没有实际生成成品文件,这也是该系统创新的地方。但是客户端预览的都是低码率的FLV素材,最终的成品参数应该是由用户自由设定的。该模块主要就是接收客户端时间线上的素材信息,并将它按照一定的逻辑处理,表示成XML的形式,发送给渲染系统进行成品的生成得到高码率的成品文件。

3 系统测试

系统测试主要从功能测试和性能测试来分别进行。功能测试主要测试了制作客户端模块的功能性问题,比如视频预览是否正常、特效是否正常等,性能测试主要是针对协同服务器的处理能力,即协同服务器可以支持多少个用户同时协同制作。下面对这两部分分别进行介绍。图7是实现了的制作客户端的页面,测试都是通过它来实现的。其中左上角是素材管理模块,右边是成品预览模块,最右边是一些用户的信息,左下角即为时间线管理模块。

功能测试主要看单机制作和协同制作是否均能正常工作。单机制作主要是测试在线制作的功能,而协同制作主要是测试协同制作的功能,而这也是该系统需要解决的两个最主要的问题。单机测试主要是通过下述流程:首先通过素材检索模块检索并添加制作所需要的素材,素材添加完毕后,开始进行视频的制作,通过在时间线模块上添加删除视频、特效、字幕等操作,制作的过程中可以进行成品的预览,最后将制作最终成品所需要的信息发送到后台进行成品的生成,测试结果表明流程顺畅,功能正常。协同制作和单机制作不同的是,并不是只有一个人在制作一个视频节目,而是多个人共同操作,不同用户操作不同的时间线区域,由此来保证用户的操作不会冲突,这样多人就可以同时进行制作。在实际的测试过程中,协同功能正常。

在性能测试中,需要多个客户端同时参与测试,通过编写测试程序来进行测试。具体的方案是采用多线程模拟多个客户端,每隔10 s定时向协同管理服务器发送模拟的用户操作,每个操作的数据量大约为300 byte,正常30 min左右,保证所有的组建立成功,然后查看协同管理服务器是否可以正常工作。表1为协同管理服务器的配置。具体的测试结果如表2所示。

测试总共模拟了1 000个用户在制作进行测试。协同管理服务器必须对每个组进行分别管理,也需要进行同步的操作,管理和同步都需要消耗大量CPU资源,结果的CPU资源占用都很高。最后一种情况,因为只需要管理一个独立的组,所以主要的CPU消耗都在同步的任务上。测试结果表明协同管理服务器可以正常工作。

同时测试过程中发现若是一个组里面的用户数比较多,则服务器端执行客户端同步更新的任务时所需要的时间就比较长。假设有M个组,每组N个用户,平均每秒每个用户做S个操作,则服务器端每秒收到MNS个操作,每秒每组需要转发NS(N-1)个操作,则服务端总共需要转发MNS(N-1)个操作。显然用户总数一定的情况下,随着每组的成员数目的增加,服务端转发操作的操作也在增加,这就解释了随着组成员的数目增多,网络带宽增大的现象。

测试结果表明制作组的数目和每个组的用户数对制作管理服务器的性能都有着很大的影响。制作组太多,则由于制作管理服务器需要对不同的组进行管理,比较消耗服务器资源。每个组用户太多,协同管理服务器更新用户操作时的压力会变得很大,需要综合考虑这些因素。

4 结论分析

笔者设计的协同制作系统不但提供给了用户一个在线的非线性编辑和节目制作平台,而且具有协同制作的功能,在基于广域网环境的在线节目制作系统中具有很大的作用。

参考文献

[1]孙思慧,孙军,王兴东.面向在线制作的集群转码系统设计[J].电视技术,2010,34(1):18-21.

[2]张亚飞.至理:精通Flex网络开发技术——整合ActionScript/J avaScript/AJAX动态网站[M].北京:电子工业出版社,2009.

[3]Adobe Systems Inc.AMF3Specification[EB/OL].[2010-08-25].http://opensource.adobe.com/wiki/download/attachments/1114283/a mf3_spec_05_05_08.pdf.

[4]王宇飞.电视节目制作领域中的非线性编辑系统[J].中国有线电视,2004(5):58-60.