流媒体视频服务器设计和实现

２００９·０８中国电子商务４５　　　流媒体视频服务器设计和实现吕雪花　陆晓钧　许待文　上海阿尔卡特朗讯贝尔股份有限公司　２０１２０６【摘　要】论文基于ＭＰＥＧ压缩标准编码特性和ＲＴＳＰ协议的技术基础，提出了一个能够提供视频点播服务的流媒体应用方案。论文首先介绍了能够提供视频业务的流媒体服务系统的整体架构，以及基于宽带网络的多点部署的网络结构。实验结果表明：对于ＴＣＰ，ＵＤＰ端口事件的调度以及如何把大量的流媒体数据从磁盘空间传递到网络上成为制约流媒体服务器性能的主要因素。【关键词】流技术　流媒体　传输流（ＴＳ）　ＭＰＥＧ－２和ＭＰＥＧ－４　　１　引言流媒体技术已广泛应用于社会的各个行业、各个领域，影响着人们的生活方式和生活质量，流媒体技术在电话网（包括固定和移动电话网）、广电网、计算机网上的应用取得了迅猛发展。在Ｉｎｔｅｒｎｅｔ上流媒体技术广泛应用，如视频点播、在线影院、远程医疗、远程教育、交互式电视等，满足各个行业网络化发展的需要。由于多媒体技术的日渐成熟、手机技术的突破以及移动骨干网的扩容，给无线终端带来新的机遇和挑战，也给用户带来新的视听感受。流媒体是由各种不同软件构成的，这些软件在各个不同层面上互相通信，基本的流媒体系统包含以下３个组件：播放器（Ｐｌａｙｅｒ），用来播放流媒体的软件。服务器（Ｓｅｒｖｅｒ），用来向用户发送流媒体的软件。编码器（Ｅｎｃｏｄｅ），用来将原始的音频视频转化为流媒体格式的软件。这些组件之间通过特定的协议互相通信，按照特定的格式互相交换文件数据。有些文件中包含了由特定编解码器解码的数据，这种编解码器通过特定算法压缩文件的数据量。其中流媒体视频服务器是３个组件中的一个部分。通常实现的功能有：（１）响应客户的请求，把媒体数据传送给客户。流媒体服务器在流媒体传送期间必须与客户的播放器保持双向通信（这种通信是必需的，因为客户可能随时暂停或快放一个文件）。（２）响应广播的同时能够及时处理新接收的实时广播数据，并将其编码。（３）可提供其他额外功能，如：数字权限管理（ＤＲＭ），插播广告，分割或镜像其他服务器的流，还有组播。本论文主要针对于网络视频的巨大需求和目前ＨＴＴＰ和ＦＴＰ协议提供视频文件的技术弱点，提出了用”流媒体技术”实现网络视频和在线点播的方案。考虑单个视频服务器在提供巨大用户并发点播数的局限性，设计了视频服务器的网络部署和实现方案，即可采用多点部署的系统架构，从而提高整个系统的承载终端用户的能力。分析了视频服务器的对于音视频数据编解码处理方式和具体实现，分析了ＭＥＰＧ采用的帧间压缩方式，利用帧之间的冗余信息大大减少压缩数据量，达到同样的视频质量ＭＰＥＧ－４所需的码率只有Ｍ－ＪＰＥＧ的１／３０甚至更少。并考虑到目前广播电视通常采用的ＴＳ流，所以采用ＭＰＥＧＴＳ流的的标准编解码方式，不但能够支持ＭＰＥＧ－２系统ＴＳ流，为扩展到ＭＥＰＧ－４奠定了基础。分析了流媒体服务器协议栈，并详细分析ＲＴＣＰ／ＲＴＰ和ＲＴＳＰ／ＵＤＰ这两套协议栈的优势，考虑的ＲＴＰ的一对一或一对多的传输情况下工作，提出了ＲＴＳＰ协议栈实现控制层协议，ＵＤＰ协议作为数据传输的网络协议栈方案，成功实现了视频点播服务的全过程。最后对视频服务器的性能做了分析评估，提供了本文较为优秀视频服务器的性能报告和分析结论，并为今后的视频服务器进一步性能调优提供方案。２　视频服务器设计方案和实现２．１　网络部署图２．１　视频服务器网路部署图任何一个视频服务器，在真正通常的视频服务器在现网，都不可能独立部署一个或若干个，如果一个视频服务器的点播并发３００个终端用户，整个网络需要负载３０００个终端用户，是否需要提供１０个视频服务器呢？经过比较和分析，论文采用多节点部署视频服务器的方案，针对于用户的操作模型，如上图的２级节点部署，也就是中央与边缘节点部署；ＳＴＢ的访问请求由ＣＤＮ系统控制，从中心节点分发到边缘节点，除了ＣＤＮ系统外，需要创建一套中央ＲＴＳＭａｎａｇｅｍｅｎｔ，集中管理视频服务器和节点管理，并相应分派服务请求；采用这种方案，可以大大降低整个方案的性能压力，从而提高网络的负载能力。系统架构论文的视频服务器，整体结构如下：图２．２　视频服务器系统架构图４６　　　中国电子商务２００９·０８虚线左边的部分，是一个独立的进程ＲＴＳＰｓｅｒｖｅｒ，负责ＲＴＳＰ信令的交互和会话的管理，以及服务器状态的收集和监控。主要由ＲＴＳＰｍａｎａｇｅｒ和Ｃｏｎｔｒｏｌｃｅｎｔｒｅ两个模块构成。虚线右边的部分是ＲＴＳＡｇｅｎｔ，可以是多个进程，主要完成ＴＳ流解析，做索引，以及媒体流发送任务。ＲＴＳＰｓｅｒｖｅｒ和ＲＴＳＡｇｅｎｔ之间通过ＩＰＣ机制通讯。ＲＴＳａｇｅｎｔ专门负责ＶＯＤ点播功能，这样可以满足ＶＯＤ的需求。采用分离进程的原因是在３２位的平台下，一个独立进程能访问的内存的限制是４Ｇ，除去系统的额外开销，真正能访问的内存的大小是小于４Ｇ的（ｗｉｎ３２下３Ｇ）。另一方面，从系统的稳定性考虑，如果子进程因为某种原因而被终止，不会影响主进程的运行。而如果我们使用６４位编程，则可以采用另一种模式，即全部的功能放在一个进程中完成。这样的好处是接口比较简单，程序的开发的复杂度会较低，不需要引入ＩＰＣ等复杂的机制。但在论文中，由于３２位到６４位移植中引发的一些问题，暂时不考虑６４位编程。Ｌｉｎｕｘ下的服务程序多采用Ｄｅａｍｏｎ程序，但我们目前的中，也不考虑这个问题，因为可能会存在一定的复杂性以及不确定因素。视频服务器起只作为一个普通程序，用脚本的方式启动，编写随系统自动启动的脚本就可以实现开机启动的功能。对于ＲＴＳＰＳｅｒｖｅｒ和ＲＴＳＰＡｇｅｎｔ是否支持分开部署，比如分别安装在２台机器上；如果支持，那么ＲＴＳＰＳｅｒｖｅｒ可以考虑支持本地负载均衡，则ＳＤＰ负载全局负载均衡。考虑到时间和精力，论文中暂时不考虑ＲＴＳＰＳｅｒｖｅｒ和ＲＴＳＰＡｇｅｎｔ分开部署的方案。考虑到视频服务器的模块比较复杂，接下来的章节分析几个主要逻辑模块，主要从架构和功能描述２个方面来分析。ＲＴＳＰＳｅｒｖｅｒ部件图２．３　ＲＴＳＰＳｅｒｖｅｒ组件图论文的ＲＴＳＰｓｅｒｖｅｒ的主要模块构成如上图所示，ＳｅｒｖｅｒＭａｎａｇｅｒ是整个服务器的最底层，提供ＴＣＰ端口监听，连接，任务分派的功能，ＧｅｎｅｒｉｃＳｅｒｖｌｅｔ负责命令的解析，ＲＴＳＰｓｅｒｖｌｅｔ负责ＲＴＳＰ命令的处理，ＲＴＳＰｓｃｅｎａｒｉｏ负责和特定的机顶盒进行交互，Ｓｅｓｓｉｏｎｍａｎａｇｅｒ负责维护整个服务器的ＲＴＳＰｓｅｓｓｉｏｎ。而Ｃｏｎｔｒｏｌｃｅｎｔｒｅ则负责对服务器的配置，以及提取服务器的状态信息并上报。ＲＴＳＰ协议，命令解析规范符合ＲＦＣ２３２６规范。ＲＴＳＰ控制，ＲＴＳＰ的命令解释以及特定扩展和特定机顶盒相匹配，与ＲＴＳＰｓｃｅｎａｒｉｏ对应。如视频服务器的终端是ＶＬＣ或者其他机顶盒。不同的终端选用不同的ＲＴＳＰｓｃｅｎａｒｉｏ。ＲＴＳＡｇｅｎｔ的控制接口。启动命令行，指定ＲＴＳＡｇｅｎｔ启动后，通过何种方式和ＲＴＳＰｓｅｒｖｅｒ通讯。控制命令，增加用户。控制命令，用户播放操作。控制命令，删除用户。配置文件配置信息（需要重其服务器后生效）：（ＸＭＬ文件）ＲＴＳＰ监听端口号。（默认５５４，多选）最大使用内存。（默认为系统实际物理内存数，单选）ＵＲＬ路径和媒体库路径对应表。（多选）临时文件存放路径。（单选）Ｓｅｓｓｉｏｎ超时时间。ＣＰＵ报警阈值。磁盘容量报警阈值。网络报警阈值。采样中（Ｓａｍｐｌｅ）的包（Ｐａｃｋｅｔ）个数，大于零的数值有效，０表示自动决定（由ＰＣＲ决定）。配置信息的更新。可以直接修改配置文件的方式，但必须重起服务器后生效。动态修改会反写配置文件，动态配置的都是频道，这些信息会实时更新到文件中。ＭｅｄｉａＬｉｂｒａｒｙ部件图２．４　媒体库组件图ＭｅｄｉａＬｉｂｒａｒｙ负责服务器媒体数据的组织和管理，内存的分配和释放。ＭｅｄｉａＬｉｂｒａｒｙ主要由ＭｅｄｉａＦａｃｔｏｒｙ和ＭｅｄｉａＰｒｅｐｒｏｃｅｓｓ这２个部件组成。ＭｅｄｉａＰｒｅｐｒｏｃｅｓｓ部件负责加载片源至内存模块中ＭｅｄｉａＦａｃｔｏｒｙ；ＭｅｄｉａＦａｃｔｏｒｙ部件主要管理已经加载至内存中的媒体数据统一的媒体数据创建接口。统一的媒体文件数据访问接口。提供统一的内存释放机制。提供可替换的内存管理策略。ＭｅｄｉａＰｒｅｐｒｏｃｅｓｓ部件图２．５　ＭｅｄｉａＰｒｅＰｒｏｃｅｓｓ组件图２００９·０８中国电子商务４７　　　媒体文件预处理模块通过ＦｉｌｅＬｏａｄｅｒ模块和ＴＳＰａｒｓｅｒ模块，将用户点播的ｆｉｌｅ加载至文件的内存中。该模块是ＲＴＳＡｇｅｎｔ中的一部分，用来采集ＢＴＶ数据并进行实时处理。ＴＳＰａｒｓｅｒ提供基本的ＴＳ流的解析，由上层的处理模块决定处理的结果。所以，其结果可供Ｆｉｌｅｉｎｄｅｘｅｒ产生ＶＯＤ点播所用的索引文件。文件节目的处理需要经过两步：做索引，生成索引文件和Ｉ帧文件，这是通过一个独立的进程在文件上传到服务器上后完成的；媒体数据装载，从第一步生成的索引文件和Ｉ帧文件生成内存中的数据，这是在用户发出点播请求后执行的。时移和点播操作上的差异是因为时移的数据输入量小而稳定，所以操作可以在实时一次完成，而对点播的文件来说，处理量是很大的。所以需要通过中间的索引文件来简化服务器模块，加快处理过程。输入可以是文件源。格式统一为ＭＰＥＧ４－ＴＳ流。输出是索引文件。提供采集数据的基本信息（时长、码率、帧率）等。Ｅｎｇｉｎｅ＆Ｐｕｍｐ部件图２．６　发送模块组件图ＵＤＰ视频数据由Ｅｎｇｉｎｅ决定那个Ｐｕｍｐ发送，每一个ｕｓｅｒ会建立一个自己的Ｐｕｍｐ。论文采用模块负责将媒体数据发送给用户，机顶盒发出播放请求之后，服务器通过模块将媒体数据发出。每一个Ｐｕｍｐ对应一个用户，单个的Ｐｕｍｐ维护和此用户相关的播放状态，并实现包括快进、快退、暂停等功能。服务器的性能总是有限的，在单个的Ｅｎｇｉｎｅ上，如果用户数过多，则会产生处理性能不足的情况，论文中分两个层面来处理这个问题：首先考虑如何检测性能不足，如何检测性能不足可以通过两个检查点完成，一是Ｅｎｇｉｎｅ中的ｏｖｅｒｌｏａｄ标记，此标记表明服务器的某次循环因为性能原因无法在限定的时间内完成。二是Ｐｕｍｐ中的发送时间戳和媒体时间戳的偏移增量，如果偏移增量持续增长，则表明服务器没有能力将数据在限定的时间内将数据发出。数据通过ＵＤＰ发送，所以客户端不会影响到服务器的发送，因为没有响应。客户端不可达（准确地说，客户端没有ｒｅｃｖ的话），会发送ＩＣＭＰ消息，服务端就可以知道客户端断开了，服务端可以选择停止发送（目前Ｃｏｎｃｕｒｒｅｎｔ就是这样做的）。其次论文中进行性能不足的处理，如果在某个Ｅｎｇｉｎｅ上出现性能不足的情况，首先需要断开Ｅｎｇｉｎｅ上的某些Ｐｕｍｐ来释放一定的资源，这里采用的策略是释放那些生命期较短的Ｐｕｍｐ。其次，如果在ＣＰＵ能力足够的情况下，可以通过开新的Ｅｎｇｉｎｅ来满足新的点播请求，前面提到的Ｐｕｍｐ可以挂在新的Ｅｎｇｉｎｅ上处理，另一种策略是根据ＣＰＵ的个数实现决定好Ｅｎｇｉｎｅ的个数。同时Ｅｎｇｉｎｅ也可以反映自己的负载量，方便新的任务的分配决策。所以，Ｅｎｇｉｎｅ的性能由其每次循环的工作时间和预设循环时间的差值计算，如果超过了，则说明超载，如果每超过，则说明ＣＰＵ还有余力。在估算Ｅｎｇｉｎｅ性能的时候，我们会留一定的余量，这样，在阈值内能保证现有客户的服务质量，超过了这个阈值，我们就拒绝新的连接，从采集模块获得数据进行发送。提供流的发送控制接口，如快进快退、暂停、继续，检索等。提供数据统计接口，如当前发送速率，已发送的数据量等。３　性能测试和分析测试方案将主要基于ＤＥＬＬ２９５０（２ｕａｄ－ＣｏｒｅＸｅｏｎＰｒｏ５３１０／４ＧＭＥＭ／１Ｇｂｉｔ）＋ＲＨＥＳ４３２ｂｉｔ＋ＦＵＪＩＴＳＵＥ２０００（１４６ｘ１２ｘ２）外挂磁盘存储。除了功能测试外，需要进行详细的性能测试，监控在不同的服务状态下网络ＩＯ、磁盘ＩＯ、ＣＰＵ、内存的使用状态。测试需要１Ｇｂｉｔ级别的光纤交换网络。