让在线教学更灵活，你还需知道：

如何让Sakai里的视频“活”起来

　　作为世界上最大的开源教学平台，Sakai系统对视频功能的支持却相对简单，难以满足高校日常化教学的需要，这也是目前很多高校在使用Sakai来建设教学平台过程中面对的共同问题。

　　Sakai是由美国印第安纳大学、密西根大学、斯坦福大学、麻省理工学院于2004年共同开发的开源课程管理系统；目前，Sakai在世界范围内被广泛使用，在国内外一流高校中的应用尤为普遍，已日益成为高校教学过程中的重要手段。

　　Sakai系统以J2EE中的Spring+Hibernate框架作为其基本框架，为用户提供基本表示层和交互服务；具体的教学功能主要以工具插件的形式给用户提供服务，如通知、日程、课程大纲、论坛、作业、在线测试等工具，为用户提供课程内容组织、课程资源管理、在线交流等服务。

　　近年来，随着视频公开课和MOOC的发展，教学视频逐渐成为各类教学平台的核心内容。以教学和视频为关键字搜索近十年的研究文献，先以“视频”和“教学”同时为关键字搜索的文献数量，再单独以“教学”为关键字搜索到的文献情况，结果如表1：

　　表1中各列第二行与第三行的比例，可以视作教学研究中对视频研究的热度，如图1所示。

　　从图1中不难发现，近十年对教学视频的研究呈迅速增长的态势，尤其是从2012年开始，随着MOOC的兴起，在教学平台中引入教学视频迅速成为近年教学研究的热点。然而，这一波研究浪潮与Sakai教学平台关联甚少。以Sakai和视频为关键字进行搜索，仅搜到两篇文献。《视频播放控件在Sakai中的兼容性实践》从本地化的角度，针对Sakai自带视频插件的编码问题，分析了不能正常播放教学视频的原因，并提出了解决方法；《开源视频系统在Sakai中的集成与应用》引入了开源视频系统Kaltura，使用插件开发的方式拓展Sakai系统对视频的支持。

　　作为世界上最大的开源教学平台，Sakai系统对视频功能的支持却相对简单，难以满足高校日常化教学的需要，这也是目前很多高校在使用Sakai来建设教学平台过程中面对的共同问题；而目前已有研究仅仅局限对本地化问题的解决和独立插件与开源系统对接，没有考虑到视频资源与其他教学资源以及知识单元的关联性，难以实现在教学平台中将教学内容与视频的深入整合，因此有必要对Sakai与视频的契合展开研究，这也是本文的研究起点。

系统架构设计

　　针对Sakai平台对视频支持薄弱这一现状，笔者从Sakai视频支持框架着手，分析该框架存在的缺陷，并对Sakai教学平台视频支持实施重新设计，将视频服务从Sakai平台的耦合中独立出来，同时对Sakai的教学资源整合工具Lessonbuilder进行二次开发，并与视频平台进行对接，从而优化视频资源的管理与提高访问视频服务的用户体验。

　　Sakai原生框架分析

　　Sakai对视频的支持零散而单一，其视频支持框架如图2所示。

　　从图2中可以看出，Sakai系统自身对视频的支持主要通过Lessonbuilder和Content组件进行集成。Lessonbuilder组件主要集成了视频上传和播放的入口，用户可以通过上传模块上传本地PC上的视频、引用视频链接以及获取已经上传的视频并将请求提交给Content组件进行后续处理，上传成功之后通过调用自带Flash视频播放器进行视频播放；Content组件是Sakai的资源统一管理组件，接收来自Lessonbuilder组件的上传请求后，将文件名进行编码并存储到Sakai自身服务器存储上，并生成文件访问映射写入数据库记录中，当接收到来自Lessonbuilder的访问视频请求时，通过数据库的映射记录来访问视频文件。

　　尽管原有的视频框架能够满足最基本的视频资源需求，但同时也伴随着无法忽视的缺陷：

　　1.视频播放存在性能瓶颈。

　　相对于教学平台的其他功能模块，视频上传、存储及播放有其特殊性，随着视频资源及的用户数增加，对服务器的CPU、内存、I/O、带宽、存储空间的要求会急剧增加，从而影响教学平台其他基本功能的响应，造成系统等待超时甚至宕机，这是非常大的故障风险点。

　　2.视频播放器的兼容性较差。

　　Sakai系统自带视频播放器对视频文件的兼容性及用户终端对视频播放器的兼容性都有一定的问题。在Lessonbuilder组件中上传视频资源后，系统自动调用Flash播放器进行视频播放，而Flash视频播放器本身支持的视频格式较少。同时，随着移动设备的普及与校园无线网络的全覆盖，越来越多的人使用各种移动终端来访问系统，而Sakai自带Flash播放器在移动设备上的兼容性较差，在这些终端上往往无法正常播放。

　　3.视频管理缺乏统一标准。

　　在Sakai教学平台中，系统本身对上传视频的格式没有任何过滤和限制，也没有提供统一转换视频编码的功能支持，用户可以上传任意格式的视频甚至非视频文件，而实际上由于其自带播放器在兼容性上的缺陷，从而导致了并不是每个上传的视频都能够正常播放，同时也造成了资源管理上的混乱。

　　Sakai新框架设计

　　针对原有视频支持框架的弊端，对视频框架进行重新设计，如图3所示。

　　在新的视频框架中，将视频服务独立出来，以接口服务的形式对Sakai系统中的组件提供支持。同时，对Lessonbuilder组件中的用户层进行二次开发，调用视频平台上传接口进行视频资源上传，并将返回的视频访问信息存入数据库，实现本地仅仅存放引用，而不存放文件本身。另外，替换Lessonbuilder组件自带视频播放器，结合视频平台转码服务，实现视频编码格式的统一与播放的稳定性。

　　视频上传流程设计

　　独立的视频平台能够避免多用户并发访问给教学平台本身带来额外的压力，同时新增的视频转码服务对视频的编码格式进行统一处理，增加了视频的可播放性，系统主要逻辑如图4所示。

　　视频服务器接收到上传请求时，将视频文件保存在视频服务器的存储上。目前，由于MP4几乎能够被所有移动设备、操作系统原生支持，有着非常良好的兼容性，因此采用MP4作为系统中的统一编码格式。视频服务器对用户上传的视频编码进行判断，如果不是MP4格式，则调用转码服务将其转成MP4格式之后再存储。存储成功后生成视频id并保存视频相关信息至数据库，同时返回视频的访问地址等信息。

　　视频上传结束，用户可以直接访问返回的视频播放地址，或是使用播放器进行视频播放。

　　当视频服务器接收到删除请求时，根据请求的视频id，删除相应的视频文件和数据库记录，并返回删除结果。

系统开发与集成

　　基于以上系统架构设计，需要进行视频系统开发、Lessonbuilder组件二次开发以及Sakai系统与视频系统的集成。

　　视频系统二次开发

　　为了不影响视频系统本身的正常运行，需要将待开发的功能与原有功能进行代码层面的隔离，因此需要在原有视频系统的基础上做增量开发。

　　1.基本功能分析

　　视频系统主要包括上传视频和删除视频两个功能。为了统一视频的编码格式，系统还应当包含视频编码转换的功能。

　　2.功能用例描述

　　为了增加系统的可扩展性，这里不具体定义上传和删除视频请求的客户端（Client），具体对接时再详细定义。通过用例图进行功能描述，如图5所示。

　　3.基本类与主要成员描述

　　系统收到客户端请求后，一方面要对上传的文件进行操作，另一方面需要记录视频的相关信息以及请求的相关参数，因此基本类应划分为文件操作类和数据库操作类，基本类及其主要成员如图6所示。

　　UploadHandler是处理视频上传文件的基本类，主要成员变量options是数组类型的数据，主要描述了服务器上存储视频的目录；成员方法中，handle_file_upload是处理视频文件上传的主要方法，上传完成后，再执行generate_response方法，回传相关信息给请求的客户端。

　　content_model是数据库操作基本类，主要成员变量category用来记录视频所在的栏目，便于视频的分类处理；成员方法add_content（data）在上传时将视频相关信息记录至数据库，delete_content（id，catid）方法用来删除已经存在的视频。

　　4.数据库设计

　　视频系统在存储视频时，需要将视频的相关信息存入数据库，删除视频时也需要根据数据库中已有的记录进行操作，其数据库表结构如下：

　　由于用户上传视频的编码格式多种多样，而用户观看视频使用的终端设备以及浏览器也不尽相同，很可能会因为兼容性问题而出现视频无法播放的情况。为了增加视频播放的兼容性，需要将视频的编码格式进行统一。MP4是当前世界上较为主流的一种视频封装格式，能够兼容绝大多数浏览器，更是当前流行的Html5技术原生支持的视频格式，因此在本系统中采用MP4作为统一视频编码格式。

　　FFMPEG是一个集录制、转换、音/视频编解码功能为一体的、完整的开源解决方案，支持MPEG、DivX、MPEG4、AC3、DV、FLV等40多种编码，AVI、MPEG、OGG、ASF等90多种解码，完全能够满足本系统的转码需求。

　　Lessonbuilder组件二次开发

　　Lessonbuilder是Sakai平台中的教学内容组织工具，它可以将各种教学文档、图片、音视频、作业、在线测试、讨论主题等教学元素按照特定的方式组织起来，并呈现完整的知识单元与情境，实现了各类教学资源的深度融合。

　　根据新的视频框架设计，为了与独立的视频平台进行对接，需要对Lessonbuilder组件中的视频上传模块进行二次开发，并替换播放模块中自带的播放器。

　　Lessonbuilder组建使用了RSF（Reasonable Server Faces）开发框架，RSF是一个基于Spring的轻量级开源框架，用户层使用纯XHTML模板进行开发。

　　1.前端页面开发

　　在Lessonbuilder组件中，用户层上传视频的模板文件是ShowPage.html，需要对其中的上传视频部分的代码进行二次开发，首先需要修改前台页面，主要代码如下：

　　在这个页面中主要包含两个表单，一是提交至视频服务器的表单，用来将视频文件和视频信息提交至服务器；另一个是提交至Sakai系统的隐藏表单，用来暂存视频系统返回的视频访问信息，为了简化呈现给用户的信息，这个表单在样式上对用户透明。

　　然后使用JavaScript技术开发前端上传功能，首先通过jQueryFileUpload插件上传视频文件，再使用Ajax技术提交视频相关信息至视频平台，同时将回传视频访问信息保存至Sakai系统中，主要代码如下：

　　其中，通过用户点击页面中的保存按钮，触发Ajax提交表单至视频服务器，返回的结果以JSON格式存储在msg变量中；从msg变量中解析出视频文件在服务器上的逻辑访问名，再与固定URL进行拼接，从而形成可访问的视频地址；最后通过自动触发隐藏表单中提交按钮的click事件，调用UpToLocal函数将视频信息提交至Sakai Lessonbuilder组件的控制层。

　　由于原有的Flash播放器设备兼容性较差，需要替换兼容性更好的Web播放器，这里我们选用当前较为流行的JWPlayer播放器。JWPlayer是一款开源播放器，支持响应式开发，能够兼容当下绝大多数设备。

　　由于用户可能需要在同一页面嵌入多个视频，因此使用IteamArr[i]数组循环加载需要播放的视频。

　　2.控制层开发

　　控制层主要用来获取前端页面的请求数据，并向模型发送数据。在Lessonbuilder中新建控制层SaveUploadInfo类，用来控制转发视频信息。

　　其中，使用System.currentTimeMillis函数获取当前系统时间戳，也就是视频上传的时间作为视频的唯一标识id，既能够记录视频上传的时间，又能在存入数据库时保证数据表主键的唯一性。

　　3.逻辑层开发

　　Lessonbuilder组件使用Hibernate技术存储数据，因此逻辑层开发也使用Hibernate对数据进行持久化操作。

　　4.接口开发

　　为了实现在Sakai系统中上传视频到视频系统，需要在视频系统中开发上传接口。该接口能够接收来自Sakai系统的视频上传请求，并调用基本类UploadHandler处理上传，主要代码如下：

　　代码中调用并实例化了基本类UploadHandler来处理上传，另外使用了时间戳和密钥拼接，以md5加密的方式作为上传口令，提高了接口的安全性。

　　跨域上传

　　由于大多数浏览器中存在同源策略（Same-Origin Policy）的安全限制，使得客户端脚本语言只能访问在同一域下的内容，而教学平台和视频平台是两台不同的服务器，要求数据在不同的域之间进行通信，因此会导致上传视频请求失败。

　　常用的跨域解决方案有两种，一种是JSONP方案，主要是针对同源策略不阻止浏览器脚本动态元素插入的特点，通过动态插入标签，可以实现跨域通信；另一种是CORS，它是一种跨域资源共享方案，通过新增一系列HTTP头，让服务器声明哪些来源可以通过浏览器访问该服务器上的资源。

　　由于JSONP只支持GET请求，GET请求数据大小一般限制在2k到200k范围，服务器接收GET请求数据大小一般也限制在16k以内，而一般视频文件的大小远远超过这个范围；同时，CORS不仅支持不限制大小的POST请求，也支持GET和OPTIONS请求，因此采用支持多种请求的CORS方案。

　　在视频服务器上的上传接口中添加接受跨域请求的声明。

　　服务器返回如下响应头，即表示该服务器接收了客户端浏览器的跨域请求，如图7所示。

系统应用效果

　　功能实现效果

　　1.上传视频

　　在课程信息（Lessonbuilder）页面中点击添加视频，弹出添加视频对话框。

　　点击“选择本地文件按钮”，选则用户电脑上的视频文件上传至视频平台；然后填写视频标题，点击“保存”按钮，先后触发将视频信息保存在视频平台，并将回传的视频访问地址保存在Sakai系统中。

　　2.播放视频

　　视频上传完成后，页面上就可以看到刚刚上传的视频。

　　在浏览器下方显示的请求信息中，视频的请求URL为视频平台的地址，用户观看视频时实际上是在访问视频平台，从而减少了对教学平台服务器带宽、存储空间等资源的占用，实现了视频服务的独立。

　　系统应用的关注点

　　1.视频转码方式的考量

　　在实际应用中视频转码的处理不见得一定依赖于平台。对用户来说，在本地使用转码工具转码后再上传，需要少量的本地操作，比直接上传转码略多一些操作的时间；然而当视频文件体积较大或者网络情况较差时，大大增加的等待时间会带来一定的不确定性，上传操作会一直占用页面，由于HTTP上传无法暂停，视频上传一旦中断，用户必须重新上传，大大降低了用户体验。

　　同时，由于视频转码主要与CPU频率相关，随着个人PC的飞速发展，用户终端的CPU频率往往不逊于服务器CPU，而网络传输与并发压力往往带来一定的不确定性。因此建议在页面上增加提示信息，提示用户尽量上传MP4格式的视频以减少等待时间。

　　2.视频平台选型的考量

　　在视频平台选型方面，一般有商业平台和开源平台两种选择。商业平台的优势在于有完善的项目和案例经验，有专门的商业团队承担平台的部署实施和运维，节省了高校信息化部门的人力成本，不足之处在于平台核心代码封闭，难以了解平台内部运行机制，定制较为困难；开源平台的优势在于核心代码开放，可以针对特定需求灵活定制，缺点是需要对开源平台进行大量深入的研究与本地化工作，部署开发与维护的人力成本较高，同时平台迭代速度较快，定制开发在平台升级后会产生额外的功能迁移工作。

　　由于作者所在学校已经存在一套正在运行的商业视频平台，因此没有尝试使用开源的视频平台。本文中所有的研发工作都是在不影响原有平台功能的基础上做的增量，开发了教学平台上传视频的专用接口。

　　本文在分析Sakai架构的基础上，针对Sakai目前对视频支持不足的问题，进行了视频服务集成开发过程及使用效果，为完善高校教学使用Sakai建设教学平台起到了积极的作用。同时，独立出来的视频服务，日后也可以应用在其他平台上，为高校集成视频服务建设提供一种思路。为了提升整体教学平台的可用性，笔者的后续研究将关注以下几点：（1）增加数据收集功能，能够统计Sakai里使用了视频整合这块的课程，分析视频整合工具的使用率，关注视频应用的实际效果；（2）关注视频平台的性能，以及可行的提升性能的手段。

　　（作者：马晨辉1 赵春1，2 徐艳艳1 沈富可1；单位：1为华东师范大学信息化办公室，2为华东师范大学教育学部教育信息技术学系）

　　（注：本文中有大量代码，由于版面原因不能全部展示，完整版本可参照《中国教育网络》8月刊电子版，网址为：www.media.edu.cn）