首页 > 代码库 > dlna（Upnp媒体服务器）开发
dlna（Upnp媒体服务器）开发
随着移动互联网潮流，多设备互动逐渐走入人们生活。比如，手机QQ和PC之间的文件共享，手机可以观看PC上的视频，智能路由器等。而相关的尝试在很久以前就开始了，比如Upnp和dlna。dlna是一堆业界大哥，将很多其它协议组合起来，在此基础定义了一些设备，交互，使得设备之间的媒体互联变得可能。而其中Upnp是核心协议，在底层基于PTC/IP，涉及DHCP等，都是被广泛使用的协议。而在上层还需要抽象出一些dlna设备，对媒体流的描述，这就是dlna了。
Upnp是intel首先发起，并提供开源实现（libupnp），后来又发生一些变化，目前还是能下载到该开源开发包。而网上有相关的开发文档：UPnP编程指南.pdf，UPNP[1].0-Chinese_UPNP中文版。而对于Upnp本身，比较重要的协议有UPnP-arch-DeviceArchitecture-v1.0-20081015，基本上奠定了Upnp基础，在此之上还定义了一些应用，比如媒体服务，其中定义了整个媒体服务的架构，其中包含媒体服务器，内容服务，连接管理，媒体传输，渲染控制，进而实现媒体的资源共享，互动。
而在Upnp的基本架构中，分为寻址,发现,描述,控制,事件,展示6个方面，解决了如何在网络中自动发现设备，知道设备的属性，控制设备进行某些操作，接收设备上的事件通知等问题。
由于是PC端使用的sdk，主要考虑PC作为媒体服务器，将PC上的媒体共享到其它设备上的功能。（其实编译为移动端的so也行）
libupnp提供什么样的api来方便构建Upnp应用呢，这里基于ushare来简单说明（可以看作是ushare的简单介绍）。
首先sdk内部会有机制负责Upnp设备的查找，发现，控制。而暴露给用户的接口就是注册设备及其回调，设备操作api，注册控制点回调等。其次，sdk实现一个WebServer，使得用户可以实现一个Web服务器。因为Upnp很多数据交互是基于http的。
然而，该sdk有些不足：只能注册一个设备，只能在一个网络工作。不过考虑使用sdk的场景，一个设备足以，通过在上面添加更多的Service使得设备可扩展。而在一个网络工作也能满足绝大多数场景的使用：在一个家庭网络中，PC有多个IP，且每个网络都有媒体需求的场景是少见的。
目前为止，使用该sdk来实现媒体服务器，需要如下流程：
初始化Upnp->启动WebWerver并注册回调->注册设备和回调->注册控制点回调。
我们假定把D盘下一个叫作server_root的文件夹共享出去，那么需要做什么呢？
首先需要设备描述，服务描述，这是MediaService中所定义的。
然后要的是共享文件的元信息，构造一个内部的数据结构，使得其中有文件夹下面所有文件的信息。元信息的获取可以在服务启动时同步获取。
接着是实现设备回调。最重要的莫过于控制动作回调，其它的比如定阅，获取变量等暂时不用考虑。实现完控制动作回调基本上服务就可用了。而控制动作回调中最重要的就是实现浏览的功能。这样客户端就可以知道根目录下的item列表，列表下面的item的属性。这样的动作是在UPnP-av-ContentDirectory-v1-Service-20020625中所描述的：媒体服务器下面的内容目录服务，服务器描述了浏览动作应该带的参数，做出的回应。要做出对应的回应逻辑，只需要知道上述文件元信息。
最后是实现文件内容传输。上面在生成浏览动作的返回数据时，里面的item中包含了文件内容的url，向该url发请求时会由sdk的WebServer处理，然后产生回调。回调就是个文件IO，包含获取文件信息，打开文件，读文件，写文件，Seek，关闭文件。用户需要根据回调时传入的url找到对应的文件元信息，然后做出对应动作即可。比如在打开文件的时候，创建一个文件信息，文件信息中包含文件句柄，读位置等，然后这个文件信息作为cookie给WebServer。在读文件的时候这个Cookie还带着，于是就可以读一段数据传回去。
至此，实现媒体服务器已经很清楚了，但是，只能共享一个文件目录。更多功能的扩展需要修改文件元信息的定义，比如引入虚拟目录。可以让在浏览动作中不可见，但是用户访问url会返回数据吗？可以，实现非常简单。
然而，构建文件元信息比较耗时，怎么解决呢？
可以建个信息缓存。可以分段加载文件元信息。
如何保证目录里和磁盘上的文件同步呢？
可以通过一些系统机制实现。不过一般没必要。
而媒体服务器的效果可以参考小度wifi（影音共享，隔空传物），百度影音打开局域网dlna共享后可以在lan内观看百度影音上的影片（不仅是PC上的，互联网上的影片也可以）。
Upnp是intel首先发起，并提供开源实现（libupnp），后来又发生一些变化，目前还是能下载到该开源开发包。而网上有相关的开发文档：UPnP编程指南.pdf，UPNP[1].0-Chinese_UPNP中文版。而对于Upnp本身，比较重要的协议有UPnP-arch-DeviceArchitecture-v1.0-20081015，基本上奠定了Upnp基础，在此之上还定义了一些应用，比如媒体服务，其中定义了整个媒体服务的架构，其中包含媒体服务器，内容服务，连接管理，媒体传输，渲染控制，进而实现媒体的资源共享，互动。
而在Upnp的基本架构中，分为寻址,发现,描述,控制,事件,展示6个方面，解决了如何在网络中自动发现设备，知道设备的属性，控制设备进行某些操作，接收设备上的事件通知等问题。
由于是PC端使用的sdk，主要考虑PC作为媒体服务器，将PC上的媒体共享到其它设备上的功能。（其实编译为移动端的so也行）
libupnp提供什么样的api来方便构建Upnp应用呢，这里基于ushare来简单说明（可以看作是ushare的简单介绍）。
首先sdk内部会有机制负责Upnp设备的查找，发现，控制。而暴露给用户的接口就是注册设备及其回调，设备操作api，注册控制点回调等。其次，sdk实现一个WebServer，使得用户可以实现一个Web服务器。因为Upnp很多数据交互是基于http的。
然而，该sdk有些不足：只能注册一个设备，只能在一个网络工作。不过考虑使用sdk的场景，一个设备足以，通过在上面添加更多的Service使得设备可扩展。而在一个网络工作也能满足绝大多数场景的使用：在一个家庭网络中，PC有多个IP，且每个网络都有媒体需求的场景是少见的。
目前为止，使用该sdk来实现媒体服务器，需要如下流程：
初始化Upnp->启动WebWerver并注册回调->注册设备和回调->注册控制点回调。
我们假定把D盘下一个叫作server_root的文件夹共享出去，那么需要做什么呢？
首先需要设备描述，服务描述，这是MediaService中所定义的。
然后要的是共享文件的元信息，构造一个内部的数据结构，使得其中有文件夹下面所有文件的信息。元信息的获取可以在服务启动时同步获取。
接着是实现设备回调。最重要的莫过于控制动作回调，其它的比如定阅，获取变量等暂时不用考虑。实现完控制动作回调基本上服务就可用了。而控制动作回调中最重要的就是实现浏览的功能。这样客户端就可以知道根目录下的item列表，列表下面的item的属性。这样的动作是在UPnP-av-ContentDirectory-v1-Service-20020625中所描述的：媒体服务器下面的内容目录服务，服务器描述了浏览动作应该带的参数，做出的回应。要做出对应的回应逻辑，只需要知道上述文件元信息。
最后是实现文件内容传输。上面在生成浏览动作的返回数据时，里面的item中包含了文件内容的url，向该url发请求时会由sdk的WebServer处理，然后产生回调。回调就是个文件IO，包含获取文件信息，打开文件，读文件，写文件，Seek，关闭文件。用户需要根据回调时传入的url找到对应的文件元信息，然后做出对应动作即可。比如在打开文件的时候，创建一个文件信息，文件信息中包含文件句柄，读位置等，然后这个文件信息作为cookie给WebServer。在读文件的时候这个Cookie还带着，于是就可以读一段数据传回去。
至此，实现媒体服务器已经很清楚了，但是，只能共享一个文件目录。更多功能的扩展需要修改文件元信息的定义，比如引入虚拟目录。可以让在浏览动作中不可见，但是用户访问url会返回数据吗？可以，实现非常简单。
然而，构建文件元信息比较耗时，怎么解决呢？
可以建个信息缓存。可以分段加载文件元信息。
如何保证目录里和磁盘上的文件同步呢？
可以通过一些系统机制实现。不过一般没必要。
而媒体服务器的效果可以参考小度wifi（影音共享，隔空传物），百度影音打开局域网dlna共享后可以在lan内观看百度影音上的影片（不仅是PC上的，互联网上的影片也可以）。
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。