1 引言
通用型即插即用UPnP(Universal Plug and Play)是PnP(Device Plug and Play)的扩展,它可发现和控制各种网络设备,如网络打印机、Internet网关等,并能提供相应服务。但UPnP不是即插即用的简单扩展,它支持“0配置”和无线网络,可自动发现其他供应商提供的设备。在UPnP协议下,一个设备可动态的加入网络,获得IP地址,广播其功能,并了解其他设备的功能。很多种类的设备都可以使用UPnP协议,包括智能设备,无线设备。
UPnP使用标准的TCP/IP和Internet协议,能够很好的在现存网络中使用,使用这些标准协议使UPnP可从已有的各种经验和知识中获利,打破各种信息孤岛,越过各种物理层,可以是有线的,也可以是无线的,具有设备间的相互协作基本特点。
目前,DLNA(现代数字家庭)是一个非常活跃的领域,UPnP是其中的主流协议之一。DLNA/UPnP的远景是构建一个有线与无线的互操作网络,由个人电脑、家用电器和移动设备组成,在家庭内部实现设备互联和网络控制,从而实现影音娱乐、内容共享。
UPnP组成包括设备节点,服务节点和控制节点。在UPnP网络中,最小的可控制单位是服务,采用一系列的状态变量描述服务的“行为”和“状态”。UPnP使用各种现存的标准协议口,包括TCP/IP、HTTP,HTTPU、SSDP、GENA。使用标准化的协议保证了各种设备间的互操作性。总之,UPnP建立在各种协议之上,而不是API上,这使其能应用在各种不同的平台上。同时,建立在各种现存的标准之上,具备很强的灵活性,可很好的适应现在和将来各种网络设备的需求。
2 UPnP媒体播放器设计的基本思想
2.1 功能描述
UPnP网络媒体播放器可以提供从网络中获取的各种娱乐信息,它允许控制节点对其进行控制。此外,根据所支持协议的不同,播放器也可以提供对数据流进行控制的功能。一个标准的UPnP网络媒体播放器包含播放控制服务、连接管理服务和媒体传输服务。任何媒体播放器都至少提供两种服务:播放控制服务和连接管理服务,媒体传输服务是可选的,它取决于设备所支持的传输协议。这里设计使用的协议是HTTP GET,能提供媒体传输服务,因而可以在数据传输过程中控制数据流。
2.2 过程描述
媒体播放器可由控制节点在局域网内对媒体服务器所提供的媒体进行播放控制。媒体服务器、播放器、控制节点3者的互动过程如下:控制节点使用SSDP协议在局域网内发现一个或多个媒体服务器和媒体播放器,首先定位媒体服务器上的资源,并需明确在服务器和播放器之间传输数据所需的协议和它们都支持的数据格式。这些传输参数都被确定后,控制节点就可以对传输的内容进行控制,如播放、暂停、停止等。真正的数据传输是在服务器和媒体播放器之间直接进行的,并且独立于控制节点,因此不包含在UPnP内。即内容的传输是使用UPnP以外的协议。之后,控制节点使用媒体服务器所提供的内容目录服务来获取该服务器所支持的协议和数据类型,使用媒体播放器的连接管理服务来获取相应的信息,比较后选定双方都支持的传输协议和数据类型。在本设计中,使用的传输协议是HTTP GET,所支持的数据格式为MP3。最后,控制节点使用媒体播放器提供的媒体传输服务来控制数据流。
3 UPnP媒体播放器的实现方法
设计使用Intel公司的开源UPnP开发工具Device-Builder,在Microsoft.NET Framwork下开发。DeviceBuilder生成的UPnP协议栈由MiniServer模块、HTTP模块、线程库模块、XML解析模块及协议栈编程接口等模块组成,负责提供基本的UPnP功能,具体实现流程如下。
3.1 生成UPnP框架
使用DeviceBuilder生成相应平台上的代码,由于是在Microsoft.NET Framwork下开发,所以选择的Target Platform应为:Windows 98,NT,XP。具体功能有:寻址、发现、描述、控制、发布事件。各功能组合在一起,为媒体播放器提供UPnP能力,但Intel开发包生成的仅是一个框架,还要为其添加解码、控制功能及对播放列表的识别等。
3.2 添加媒体解码库
下载一个开源的播放器,将其改造成媒体解码库。即将播放器的功能抽象成函数以供外界调用,主要函数如下:
int decodestart(char*pBuffer):调用该函数开始播放,相当于原来播放器的play功能。pBuffer是一个公共缓冲区,存放已下载的媒体数据。
extem void Read(int*position):负责向公共缓冲区中装入已下载的媒体数据,position指针则对应于公共缓冲区中应装入的位置。由于一般下载的速度远大于解码速度,所以应注意装入新数据时不要将尚未解码的数据覆盖掉。
extern void Decode(int*Dposition):当外界调用该函数时开始解码,Dposition则指示对应于公共缓冲区的解码位置。
此外还有pause,resume,stop等函数,均对应于原播放器的相应功能。将已实现的媒体解码库添加到生成的UPnP框架,再在UPnP框架中相应的位置调用库文件中的函数以实现解码、播放控制。
3.3 播放控制功能实现
添加媒体解码库后。还需添加:数据流实时控制能力、根据播放器的状态发布消息。详细过程如下:
(1)设置传输地址 当控制节点从媒体服务器选定一首歌时,则触发设置传输地址(由媒体传输服务提供)这一动作。这时,如果播放器正在播放,首先要停止播放器的解码动作,为新歌曲的播放做准备。接下来,在播放器获得所选定歌曲的地址后(由控制节点提供),直接从媒体服务器中下载这首歌曲,在此项目中,播放器采用HTTP GET下载。下载前,还需对该URL进行判断,查看下载的是否为播放列表,如果是播放列表,就不能将其直接传给播放器,而要继续从播放列表提供的地址中得到第1首歌的URL,再从媒体服务器中下载。最后,调用函数SetLastChange发布自己的状态信息。
(2)数据流实时控制在下载的大小达到一定长度时,触发传输控制服务中Play这一动作,这时,主线程创建一个解码线程,该线程调用媒体解码库中的decodestart(char*pBuffer)函数,对存放在公用缓冲区中的数据进行解码并播放,进行同步控制,以免当网络出现拥塞或系统内存不足时,缓冲区中的播放指针超过下载指针而导致意外。如果选定的是含有多首歌曲的播放列表,则过程类似,只不过在一首歌曲播放完时会自动从媒体服务器端下载另一首歌曲,一边下载,一边播放。当用户点击next,previous时,首先检查之前保存的URL是否为播放列表,若不是,则输出错误信息;若是,则停止播放器的解码动作,撤销当前解码线程,为新歌的播放做准备。由播放列表得到下一首歌的地址和端口号,开始下载数据,并创建新的解码线程,最后,发布状态信息。
所有的实际操作,如play,stop,pause,…,均与UPnP无关,它只实现消息传递。控制节点负责接收命令传递给播放器,再由播放器中的媒体解码库完成解码、播放、暂停、停止等功能。媒体服务器、控制节点、媒体播放器的互动如图1所示。
4 测试与分析
系统开发完成后,在两台同处于一个局域网的台式机上进行测试,测试流程如下:首先在一台机上启动Intel UP-nP工具集中的AVWizard程序,该程序其实就是媒体服务器和控制节点的合体,它既能提供媒体服务器的各种功能,也可提供控制点的功能。在另一台机上启动媒体播放器,AVWizard首先扫描网络中有无它所支持的设备,发现媒体播放器后,获得该播放器的设备描述文档,并显示播放器的名称。用AvWizard选定一首MP3,并将地址发送给指定的媒体播放器(UPnP MediaRender)。播放器开始从媒体服务器指定的地址下载MP3,下载到一定长度时开始播放,详细过程描述如下:
由图2可知,当AVWizard选定一首歌曲时,播放器输出为:“Invoke:UPnPAVTransport_SetAVTransportURI…”。触发播放器中媒体传输服务中的设置传输地址这一动作.告诉播放器所需下载的媒体所在的URL和端口号,接着在AV Wizard中点击play时,可以看到图3中播放器输出为:“Invoke:UP-nPAVTransport_Play(0,1)”,触发播放器媒体传输服务中的play动作,开始下载要播放的内容,同时,播放器开始创建解码线程,输出:“Create thread success!!”,则表示解码线程创建成功,在该解码线程中调用媒体解码库中的函数。媒体解码库出:“…The main proccess start…player_init”,初始化媒体解码库,解码并开始播放音乐。
5 结论
由此可见,该媒体播放器实现成功,但存在不足之处:由于直接在Intel公司开源UPnP开发工具DeviceBuilder生成的代码上进行开发,所以界面不够友好。实现媒体播放器的创新点如下:(1)直接在Intel生成的UPnP框架上进行开发,与现有的许多使用开源UPnP SDK开发相比,无需进行设备初始化和注册工作,亦无需对UPnP的工作过程进行手动操作,使开发者的注意力可以完全集中在所需添加的服务上,无需关注繁琐的协议通信细节,简化UPnP应用的设计开发;但缺点是由于目前业界有许多SDK开发包具有类似的功能,直接使用生成的UPnP框架不利于按需更换协议库。(2)可在不同的操作系统上生成相应的协议框架,屏蔽开发平台的差异,方便开发人员在合适的平台上实现所需的服务。(3)服务本身也可以作为模块添加到应用程序中,如媒体解码库就是作为一个独立的模块添加,实现松散耦合的应用程序和组件,可根据不断变化的情况和需求来实现服务,为媒体播放器的功能扩展提供了很好的基础。