基于DLNA实现投屏的思路梳理

时间:2024-03-26 15:22:57

转自 https://blog.csdn.net/lin20044140410/article/details/100137122

基于DLNA实现投屏的思路梳理(依赖开源库cling)

  • 简介

DLAN(Digital Living Network Alliance),数字生活网络联盟。DLNA并不是创造技术,而

是形成一种解决方案,一种大家可以遵守的规范。其中选择的技术和协议都是当前应用很广泛的技术和协议。

  下图是DLNA设备的类图:

基于DLNA实现投屏的思路梳理

 从上图可以看出DLNA主要包含的产品,下面主要说明产品的基本概念,不刻意去区分家庭网络设备,还是移动端设备。实际上移动端设备只是相对于家庭设备功能更简化,媒体格式支持有区别。

  1. DMS(Digital Media Server),数字媒体服务器,媒体内容的提供者,为DMP/DMR提

供内容播放,DMS可以控制提供哪些媒体内容。典型设备如PC,数字机顶盒,手机,音乐播放器等。

  1. DMP(Digital Media Player),数字媒体播放器,可以从DMS上查找获取媒体内容并

播放,典型设备如:智能电视,

  1. DMR(Digital Media Renderer),数字媒体渲染器,可以播放DMS上的媒体内容,跟

DMP的区别是DMR只有媒体播放功能,DMP除了播放功能外,还有浏览查找媒体的功能,典型设备如:显示器,音箱。

4)DMC(Digital Media Controller),数字媒体控制器,可以查找DMS的内容,建立DMS

和DMR之间的连接,控制媒体的播放,典型设备如:遥控器。

 

  • DLAN的架构

DLNA架构是个互联系统,分以下几个层次:

基于DLNA实现投屏的思路梳理

从下往上看:

  1. NetWorking Connectivity 网络互联方式,有有线的如符合IEEE802.3标准的ethernet,有无线的,如符合IEEE802.11标准的wifi。
  2. NetWorking Stack 网络协议栈,DLNA的互联传输是在IPV4协议簇基础上的,用TCP,UDP都可以。
  3. Device Discovery & Control 设备发现和控制,DLNA用Upnp协议来实现设备的发现和控制,这块也是整个框架中最重要的一部分。

先顺序看完DLNA的框架层,后面再梳理Upnp协议。

  1. Media Management媒体管理,包括媒体的识别、管理、分发、保存。
  2. Media Transport 媒体传输,这一层用http(HyperText transfer protoco)超文本传输协议,可选协议是RTP。

Media Formats 媒体格式,下表是DLNA支持的编码格式:

基于DLNA实现投屏的思路梳理

  1. Romote UI 远程用户接口,就是遥控器。
  • Upnp网络协议

  Upnp组件

基于DLNA实现投屏的思路梳理

 

其中,根设备、设备:

设备就是指物联网设备,如:家用电器,电视盒子等。因为一台Upnp设备可以是多个服务的载体或多个子设备的嵌套,所以存在一个根设备的概念。

 

服务:是指设备所支持,能提供的服务,如支持:控制服务、事件服务、展示服务。

 

控制点:是可以发现并控制其他设备的控制设备,如android设备需要控制设备来控制投屏设备的视频播放、停止等操作,就需要控制点对设备进行控制。

 

投屏的过程,大体是:设备发现,设备控制,设备事件。

 

Upnp协议栈:

Upnp的目标是实现设备间的网络互联。

Upnp协议定义了设备之间,设备和控制点,控制点之间通信的协议。

完整的Upnp协议栈有设备寻址,设备发现、设备描述、设备控制、事件通知及基于HTML的描述等几部分构成。

 

基于DLNA实现投屏的思路梳理

上图中每一层都是以底下一层为基础,同时又是上一层的基础。

1)IP 网络协议:

因为用到网络数据的传输,IP层用于数据的发送和接收。

这里包含了UDP,TCP两块协议。

UDP协议跟IP协议组合成:UDP/IP协议。而HHTPMU,HTPU这两个协议是基于UDP/IP协议之上的。

TCP协议跟IP协议组合成:TCP/IP协议。Http是基于TCP/IP协议之上的。

 

使用UDP,可以通过多点传送(Multicast)项DLNA上所有支持UPNP的设备发送新设备接入的通知。这里的流媒体也会使用UDP来传输,因为速度快。

 

HHTPMU,HHTPU是HTTP协议的变种,这些协议的格式沿袭HTTP协议,只不过与HTTP不同的是他们通过UDP而非TCP来承载,并且可用于组播进行通信。

 

2)设备发现SSDP协议

简单服务发现协议(Simple Service Discovery Protocol :SSDP),具体包括控制点如何发现网络上有哪些服务,以及这些服务的资讯,还有控制点本身宣告它提供哪些服务。

 

    3)控制设备SOAP协议

简单对象访问协议(Simple Object Access Protocol:SOAP),它定义如何使用xml与http来执行远程过程调用,包括控制点如何发送命令消息给设备,设备收到命令消息后如何发送响应消息给控制点。

 

  1. 设备事件GENA协议

通用事件通知架构(Generic Event Notification Architecture :GENA)。

定义在控制点想要监听设备的某个服务状态变量的状况时,控制点如何传送订阅信息并如何接收这些信息。

 

  1. Upnp设备体系定义

这一层是一个抽象层,公用的设备模型,就是一个规范定义,所有的Upnp设备都必须使用这层。

 

  1. Upnp设备制造商定义

就是应用层,由Upnp设备制造商定义的部分。

 

  • Upnp的使用

Upnp是一套通用即插即用的网络协议,适用于家庭网络,设备之间的发现和互连。目标是实现任何设备只要一接入网络就能被网络中的所有其他设备发现,做到完全的即插即用。

 

Upnp的工作方式:

基于DLNA实现投屏的思路梳理

  1. 寻址

每台设备通过IP地址的方式进行寻址,设备首次加入网络时通过DHCP(Dynamic Host Configuration Protocol 动态主机配置协议)服务获取IP,或者通过静态IP设置获取IP。

 

  1. 发现

通过SSDP(简单服务发现协议)完成设备的发现。

当设备加入网络时,它向Upnp专用的组播地址(239.255.255.250:1900)发送消息宣告自己的存在。

 

 

发现框架图:

基于DLNA实现投屏的思路梳理

由上图可看出:根设备中设备和服务会以多播的形式发出通知,到控制点。

控制点会以多播形式发出search的消息到根设备,然后根设备会以reponse单播的形式响应search消息。

 

Location 设备描述文件的URL。

NOTIFY * HTTP/1.1 

Host:239.255.255.250:1900 

Cache-control:max-age=1800 

Location:http://192.168.0.1:49152/des.xml 

Nt:upnp:rootdevice 

Nts:ssdp:alive 

Usn:uuid:de5d6118-bfcb-918e-0000-00001eccef34::upnp:rootdevice 

 

Upnp控制点为发现设备将向组播发送如下消息:

M-SEARCH* HTTP/1.1 

Host:239.255.255.250:1900 

Man:"ssdp:discover" 

Mx:5 

ST:ssdp:rootdevice

 

SSDP格式的消息只有信头,没有message body。

 

  1. 描述

描述分两部分,一个是Device description,设备描述,说明这个device是什么;还有一个是service description,服务描述,说明这个服务可以做些什么。

 

设备描述文件的URL包含在设备加入网络时发送的消息中。

Location:http://192.168.0.1:49152/des.xml

这个xml,包含了设备的类型,设备提供的服务。

 

  1. 控制

Upnp通过SOAP协议控制设备,按照xml描述文件中的消息,以Device + service +action + Variable的形式控制设备。

SOAP协议是有消息内容的,message body里面可以写想调用的动作Action invocation,还可以带参数,如播放一个视频,要把视频的URL传过去,设备发送的响应消息,表示能不能执行调用,出错的了返回一个错误代码。

 

  1. 事件(Eventing)

在服务进行的整个时间内,只要变量值发生了变化或者模式的状态发生了改变,就产生了一个事件,该事件服务提供者会把该事件向整个网络进行多播(multicast),控制点可以事先向事件服务器订阅事件信息,保证整个控制点感兴趣的事件及时准确地单播传(unicast)送过来。

 

 

  • Audio/Video 设备交互模型

  针对本地媒体内容,设备控制点和数字媒体服务DMS在一个设备上,如手机;

DMP或者DMR在另一个设备上,如TV,电视盒子等。

针对网络媒体内容,设备控制点是手机,媒体内容在Server端,即DMS存在于另外一个设备上。

如下图,Control Point 跟Media Server在一个设备上,Control Point会向media Renderer推送媒体数据。

Control Point会在本地选取媒体内容,然后匹配协议/格式,最后传输媒体内容。

Media Renderer只需要匹配协议/格式,接收媒体数据。

基于DLNA实现投屏的思路梳理

整个开发内容:

  1. 需要做sink端,主要的目的是为了调试时,方便跟踪log。之前通过爱奇艺看视频时,在公司有搜索到DMR(即是DLNA的渲染端)设备,但是后来想去找整个设备时,又搜索不到了。所以,还是需要做sink端,调试方便些。
  2. 重点是Source端,也即是手机测的Control Point和DMS部分。

 

第一步:实现演示功能。

       这个过程是想通过做演示版本,来熟悉整个DLNA的框架,及其中的API的使用。

第二步:优化代码架构,方便客户任意切换开源库。

       这里的开源库主要指Upnp这块,市场上有不同的开源库,尽力去做到接口的统一,做到在客户切换不同开源库时,整个投屏的功能代码不用做修改,这是个理想的目标。能不能实现要看分析了哪些开源库的api在确定。

 

 

参考文档:

https://blog.csdn.net/zangcf/article/details/44222707

https://elinux.org/DLNA_Open_Source_Projects

https://blog.csdn.net/bao_jinyu/article/details/7532406

https://blog.csdn.net/bao_jinyu/article/details/7581101

https://www.jianshu.com/p/5a260182cc82

https://www.jianshu.com/p/bce3f4047a65