Android下WiFiDisplay功能探究.docx

上传人:牧羊曲112 文档编号:3152463 上传时间:2023-03-11 格式:DOCX 页数:15 大小:45.09KB
返回 下载 相关 举报
Android下WiFiDisplay功能探究.docx_第1页
第1页 / 共15页
Android下WiFiDisplay功能探究.docx_第2页
第2页 / 共15页
Android下WiFiDisplay功能探究.docx_第3页
第3页 / 共15页
Android下WiFiDisplay功能探究.docx_第4页
第4页 / 共15页
Android下WiFiDisplay功能探究.docx_第5页
第5页 / 共15页
亲,该文档总共15页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《Android下WiFiDisplay功能探究.docx》由会员分享,可在线阅读,更多相关《Android下WiFiDisplay功能探究.docx(15页珍藏版)》请在三一办公上搜索。

1、Android下WiFiDisplay功能探究版权声明:本文为博主原创文章,未经博主允许不得转载。 目录(?)- 1. 1 WiFiDisplay简介 1. 2. 2. 2 WiFiDisplay重要规范及标准 WiFi联盟定义了Miracast支持的视音频格式标准 主要模块介绍 1. 1 WiFiP2P 1. 2. 2. 11 WiFiP2P简介 12 Android中WiFiP2P Android下实现详述 1. 1. 32 DisplayManagerService及相关 WiFiDisplay应用场景及相关产品 1. 1. 2 相关应用产品 DLNA技术和AirPlay技术 1. 2

2、AirPlay技术 1 WiFiDisplay简介 1.1WiFiDisplay概述 WiFiDisplay(WFD)是WiFi联盟在已有技术的基础上,为了加速视/音频的传输分享而提出来的一个新概念。WiFi联盟对此成立了一个认证项目:Miracast- 用来认证一个设备是否支持WiFiDisplay功能。 下图是WiFiDisplay功能的技术支撑体系,实际上最重要的部分就是WiFi Direct:也就是两个设备无需AP(AccessPoint)的情况下直接相连,这就奠定了两个带WiFi功能的设备能够随时传递高质/高清视频的前提。另外,其他深蓝色的技术是必须支持的: 11n:即802.11n

3、协议,支持最高传输速度540Mbit/s; WMM:即WiFi Multimedia的简称,主要针对不同的数据内容保证其传输的稳定和质量; WPA2:是WiFi联盟对于采用802.11i协议并采用更为复杂加密算法的认证项目; WiFi ProtectedSteup:也是一个WiFi联盟的一个认证项目:简化用户安装无线局域网和对安全性能的配置工作; WiFi Direct:表示设备可以实现直接互联,无需AP的参与; WiFi Miracast:即为是否可以实现wifi-display功能的认证项目。 图 1 WiFiDisplay技术支撑架构 另外,WiFi联盟还描述了WiFiDisplay的简

4、化工作模型(图2)。在这个工作模型中,Miracast定义传输视/音频数据的一方为source端;接受数据并重新呈现的为sink端。从图中可以看到,source端要有数据内容的存储和下载/生成能力;对数据进行编码能力。而sink端则需要对数据的解码能力;对视/音频进行再度呈现的能力。而Miracast则是定义了这两个设备之间,怎样保持会话;可以传输数据的格式标准;会话控制等内容。 图 2 WiFiDisplay的工作模型 1.2 WiFiDisplay重要规范及标准 WiFi联盟定义了Miracast支持的视/音频格式标准:图 3 Miracast支持的显示、视频、音频格式标准 同时,Mira

5、cast也规范了设备连接后进行协商(图4)、建立会话的流程(图5)。详细描述了设备在建立物理连接后,通过标准步骤来完成WiFi Display的会话建立,然后开始数据传输。关于各个标准步骤的详细信息,请见Miracast官方解释。 图 4 Miracast定义的设备协商标准过程 图5 Miracast定义的显示会话建立过程标准 2 主要模块介绍 由于WFD功能主要涉及wifiP2P功能和display功能,现对Android中涉及的两个模块wifiP2pService和SurfaceFlinger做一些介绍。 2.1 WiFiP2P 2.1.1 WiFiP2P简介 WiFiP2P是WiFi联盟

6、提出的一项重要技术规范,它定义了两个wifi设备如何在没有路由的情形下连接并通信。根据定义,支持WiFiP2P的设备需要扮演P2P GroupOwner或P2P Client角色来形成一个P2P Group: 图6 WiFiP2P工作组模型 其中P2P Group Owner的设备需要发挥传统路由的功能:控制WiFiP2P工作组,使能设备通信等;P2PClient设备则需要连接上P2P Group Owner设备来形成一个工作组来通信。 在以上的工作模型基础上,WiFiP2P细化了以下技术项: 图7 WiFiP2P定义的P2PDiscovery规范 在P2P Discovery规范中,定义了发

7、现设备(Device Discovery )并构建工作组(GroupFormation )的细节。其中发现设备规定设备首先进入扫描阶段(ScanPhase),去发送Probe Request帧;然后进入寻找阶段(Find Phase),在这个阶段中设备会在SearchState和Listen State中切换:两个阶段分别是发送Probe Request帧、监听ProbeRequest帧并发送Probe Response帧。当找到附近的P2P设备后,就可以来构建一个工作组:包括决定谁是Group Owner的协商(GONegotiation )和设备交换安全配置信息(Provisioning)

8、,用于Client设备利用安全配置信息连接GO。 另外,WiFiP2P还定义了GroupOperation技术项,具体描述了和工作组交互的场景和流程: P2P Device Join GO(Group Owner) P2P Device Join GC(Group Client) GC invite P2P Device GO invite P2P Device 2.12 Android中WiFiP2P Android中关于WiFiP2P模块主要涉及以下几个部分: 图8 Android中WiFiP2P涉及模块 WiFiP2PSettings 是用来和用户交互的部分,主要是提供UI给用户选择打开

9、/开闭WiFiP2P功能、呈现搜寻到的P2P设备给用户等;WiFiP2PSettings实现的功能调用的是WiFiP2PManager中的接口;WiFiP2PManager最终会与WiFiP2PService交互,它们依靠Android的Binder机制来实现进程间的通信,WiFiP2PService则是用来管理Android中WiFiP2P功能的核心模块: 图9 Android中WiFiP2P涉及模块 在WiFiP2PService类中有一个内部类P2pStateMachine(状态机)用来管理WiFiP2P的不同状态然后执行不同的操作;另外WiFiP2PService还会创建一个WifiM

10、onitor对象用于接收来自wpa_supplicant的消息并根据接收到的消息给P2pStateMachine传值来推动状态机的工作。从图中可以看到,WiFiP2PService或WifiMonitor交互的是WiFiNative.Java中的接口,这里面的都是一些native函数;这是因为wap_supplicant进程是C语言实现,Android是通过JNI机制调用android_net_wifi_Wifi.cpp 里面的本地接口,这些本地接口来最终和wpa_supplicant交互(wifi.c里面是对发送到wpa_supplicant里面消息的封装)。 wpa_supplicant是

11、一个开源项目,实现了WiFi联盟规范中的众多功能,详见官方文档。下图是wpa_supplicant及与下层部件的一个草图: 图10 wpa_supplicant及底层部件草图 2.2 SurfaceFlinger 总所周知,SurfaceFlinger是Android中对图形画面进行管理并交由FrameBuffer实际显示的重要模块,它需要收集系统中所有应用程序绘制的图像数据,然后集中处理后显示到物理屏幕上。下图是Android下图形显示的一个简略框图: 图11 Android显示系统简略框图 上图描述的是使用OpenGL ES图形开发规范下的情况。首先,每个应用程序在自己的窗口上进行绘图,这

12、里的窗口(Window-2)实际上对应的是一些缓冲区;然后SurfaceFlinger则会对这些缓冲区进行统一管理;最后每一帧的图形数据会被送到FrameBuffer上并实际显示在设备上。 对于上层应用来说,Window-2在Android中的实现为SurfaceTextureClient类。由于是在OpenGL ES的开发框架下,SurfaceTextureClient实际上是继承自ANativeWindow同时在本地实现了一些接口(参见EGL知识): 图12 上层应用的window实现 hook_dequeueBuffer和hook_queueBuffer是框架定义中需要实现的本地函数,上

13、层应用作图时需要从缓冲队列得到缓冲区;作图完成后需要把缓冲区送还给缓冲队列。具体情形如下: 图13 本地窗口和缓冲队列交互图 如上图,本地窗口实际上是从BufferQueue来得到缓冲区;画图后再将缓冲区入列到缓冲队列。而BufferQueue是在应用程序创建Surface(在SurfaceFlinger端对应Layer)的时候生成的,本地窗口通过返回的ISurface对象得到ISurfaceTexture对象来最终和BufferQueue交互。 对于SurfaceFlinger侧的本地窗口Window-1(图11)来说,SurfaceTextureClient也是作为本地窗口的功能。不过在S

14、urfaceFlinger端通过标准的OpenGL ES接口进行请求缓冲区操作和入列缓冲区操作的对象就不一样了;而且在入列缓冲区后所进行的操作也不一样: 图14 SurfaceFlinger的本地窗口 如上图,在SurfaceFlinger端的本地窗口Window-1,会有自己的BufferQueue对象,而最终和HAL层的Gralloc模块交互实际分配缓冲区的时候,会根据功用不同来分配不同类型的缓冲区:上层应用分配的缓冲区是给OpenGL绘图用的;SurfaceFlinger这边分配的缓冲区是要送显FrameBuffer的(详见gralloc.h中定义)。 对于上层应用来说,填充好缓冲区后处

15、理端(consumer&producter模型)会调用到Layer文件的onFrameQueued函数,如果需要渲染图形这时候需要等待一个VSYNC信号(详见Android的Project Butter),收到VSYNC信号后会对需要渲染的Buffer按照Z轴计算可见区域并进行图像混合;而对于SurfaceFlinger端来说,缓冲区入列后consumer会最终调用fb的HAL层接口完成实际显示。 3 Android下实现详述 Android自从4.2后就支持WiFiDisplay功能了。以下是Miracast官方公布的WFD工作模块框图: 图15WiFiDisplay的工作模块框图 在以上工

16、作模型的基础上,Android主要做了以下工作: 新加了WiFiDisplay的setting部分,用来为用户提供操作选项; 新加DisplayDevice类用来描述不同的显示设备,WiFiDisplay作为一个虚拟显示设备; 修改了SurfaceFlinger模块来支持WiFiDisplay,通过SF把显示内容投放到不同的设备上; 新加了DisplayManagerService来对系统的显示设备进行统一管理 根据Miracast规定的会话建立管理流程,实现了source端和sink端的程序 3.1 应用程序端 对于WiFiDisplay功能,Android提供了相应接口给应用程序使用,以实

17、现在第二显示设备上进行显示。具体内容参考官方描述,其中关键步骤见图16:图16 Android上WFD应用编程简要步骤 可以看到主要包括Presentation和MediaRouter两个class。实际上它们都会调用一个重要的class提供的功能 DisplayManager,而DisplayManager接口的具体实现在另外一个进程中的DisplayManagerService.Java文件中。 3.2 DisplayManagerService及相关 DisplayManagerService是Android中管理WiFiDisplay功能的核心服务: 图17 DisplayManage

18、rService简图 每一种显示设备(LocalDisplayDevice、WiFiDisplayDevice)都有一个对应的DisplayAdapter,DisplayManagerService通过管理这些Adapter来管理不同的显示设备。比如DisplayManager发起的对WiFiDisplay的操作请求,都会由DisplayManagerService转给WifiDisplayAdapter来实际完成。另外DisplayManagerService服务还通过WindowManagerFuncs窗口管理功能接口直接调用WindowManagerService的函数,实现窗口内容的刷

19、新;同样DisplayManagerService服务还通过InputManagerFuncs接口直接调用InputManagerService的函数,用来设置输入系统需要的显示器的显示视图信息。 而WifiDisplayAdapter的操作最终会实现在WifiDisplayController中,去实现设备扫描、设备连接等操作: 图18 WifiDisplayController简图 关于和其他设备的WiFiDirect连接,Android有专门的一个WifiP2pService来管理,这里对于设备的连接就是直接调用WifiP2pManager(和WifiP2pService交互)所提供的接

20、口来完成。 3.3 Source/Sink设备会话管理端 在设备建立WiFi连接后,会在RemoteDisplay上监听RTSP的连接,用于后续创建session和传输实时流数据。 图19 监听RTSP连接流程简图 如上图,实际的监听最终流程会走到RemoteDisplay中,即一个RemoteDisplay对象的创建。通过创建这个本地的RemoteDisplay对象将会创建一个ANetworkSession对象,用于管理网络部分的操作;创建一个ALooper对象,实现各类消息的派发和处理;创建一个WifiDisplaySource对象(由于搭载Android系统的大多数设备在WiFiDisp

21、lay场景中,多数会扮演source端的角色,因此这里创建的是WifiDisplaySource对象),具体处理各类消息: 图20 RemoteDisplay简图 另外,Source目录还包括PlaybackSession.cpp、MediaPuller.cpp、Converter.cpp、TSPacketizer.cpp、Sender.cpp等C+类文件和相应的头文件,分别负责Source端的会话过程管理、镜像媒体读取、编码、TS打包及RTP打包发送等过程。Converter 对象中包括一个MediaCodec对象具体负责编码过程,MediaCodec对象实际通过ACodec对象调用IOMX

22、接口使用OPENOMX媒体框架完成镜像数据的编码。 3.4 视/音频数据获取方式 图21 source端的媒体数据获取简图 如图,source设备端程序对要在远端设备进行呈现的视/音频数据通过MediaSource类进行管理。上图中的SurfaceMediaSource和AudioSource都是继承自MediaSource类,它们分别对应视频数据和音频数据,根据不同的情景,source设备端程序可以添加视频或者音频数据源到当前程序中来,而且每一个MediaSource会对应创建一个Converter对象和一个MediaPuller对象,用于媒体数据的编码和数据读取等操作。下图是获取视频数据的

23、程序片段,调用MediaSource的通用接口read来实现。 图22 获取视频数据程序片段 3.4.1 视频数据源 由图22可知,视频数据是从一个BufferQueue中读取的。上层应用正是将需要显示的视频数据放到和这个BufferQueue对应的Surface中,实现视频数据的远端设备投递。 图23 SurfaceFlinger管理不同显示设备简图 较详细来说,上文中的surface是由WiFiDisplayDevice所持有的,这部分内容还和SurfaceFlinger为支持画面投递到不同的设备上而进行的改动有关。如图23,主要是抽象了DisplayDevice来表述本地显示设备和WiF

24、iDisplay等显示设备,在SurfaceFlinger.cpp的handleTransactionLocked函数中可以看到: 图24 SurfaceFlinge对不同显示设备处理代码片段 对于virtualDisplay的话(WiFiDisplay设备),mFramebufferSurface为空;SurfaceTextureClient直接使用了State信息中携带的surface变量。这个Surface正是当RTSP建立后,在回调函数onDisplayConnected中注册到SufaceFlinger中的(3.3节描述监听连接),这样SurfaceFlinger会将上层应用的显示数

25、据投递到这个Surface上面,而source端的程序则会从这个surface上取出数据。 3.4.2 音频数据源 由图21可以看到,音频数据的获取是通过AudioRecod来得到。Android系统对于Audio系统抽象了AudioTrack对象和AudioRecord对象来分别用于音频数据的输出和音频数据的采集/获取。对于WiFiDisplay情景下的音频数据处理,Android也是在不破坏原有架构的情况进行的: 图25 WFD情景下音频简单架构图 AudioRecord通过AudioSystem对象来获得AudioFlinger和AudioPolicyService的远端接口进行操作,最

26、终和HAL层的module交互,实际上完成的是从一个管道中的读取操作;而AndroidTrack也是基于同样的模型,只不过流程相反,完成的是向HAL层的一个对应管道中的写操作。其中AudioPolicyService在Android关于Audio的各个组件中扮演着核心角色: 图26 AudioPolicyService核心与其他组件交互图 如上图,详细来说:AudioPolicyService直接交互的是一个称为POLICY的HAL层模块,这个模块提供了通用接口;然后通用接口会调用到一个具体的策略管理类中提供的接口,对应上图的AudioPolicyManagerALSA;最终,会根据不同的调用

27、参数来获取真正的HAL层模块,和硬件交互,而AudioFlinger得到具体的HAL层模块后,就可以直接对其操作了。 这些具体的HAL模块,ID名称都为AUDIO_HARDWARE_MODULE_ID ,只是被编译成了不同名称的库文件,而对应于WiFiDisplay的HAL层模块不需要和具体的硬件打交道,实际实现为一个管道: 图27 WiFiDisplay的HAL模块程序片段 因此,对于需要通过WiFiDisplay到远端设备进行呈现的音频数据,只需要使用AudioTrack的接口来把音频数据放到上文HAL模块中的管道;而WiFiDisplay的source程序端也只需要调用AudioReco

28、rd的接口取出数据即可。最发送前的编码,音频/视频打包则专门去处理,不破坏原有的系统架构。 4 WiFiDisplay应用场景及相关产品 4.1 主要应用场景 WiFiDisplay技术实现视/音频数据的无线远端呈现,目前涉及视/音频数据处理的设备较多,常用的应用场景有: 1、数字播放器和数字电视工作场景:在这个应用场景下,由于source端设备不具有用户交互屏幕,因此sink端设备需要和用户交互完成设备的配对、传输的控制等工作; 图28 WFD应用场景1 2、下图描述的是一个数字机顶盒和DTV加上一个AP的工作模型,source设备在这个模型中同时连接到AP和sink设备,source端的数

29、据此时是从网络获取的。这在WiFiDirect模型中是允许的,对于P2P连接在底层实际上对应的一个虚拟地址。 图28 WFD应用场景2 3、下图是描述的是有两个sink端设备的应用场景,此时source设备需要发现和连接两个sink设备,并发送视频/音频数据到不同的sink设备上。同时两个sink设备也需要彼此通信,来做同步和其他信息交换。 图28 WFD应用场景3 4.2 相关应用产品 WiFiDisplay的应用产品,市场上已经有一些,比如百度推出的百度影音棒、小米盒子等。其中百度影音棒的工作情况如下:(官方说明) 图29 百度影音棒2S工作简图 百度开发出的百度影音棒系列,实际上一种充分

30、考虑现实情况的一套无线视频播放方案。由上图可知,考虑到现有电视的实际情形(大多数只带HDMI功能),这套方案对于TV还是使用HDMI和BaiDu 2S有线连接,而真正的无线模块则是这里的BaiDu 2S。这里的source设备即为手机,sink端设备其实就是BaiDu 2S。 小米盒子和上图的工作模型基本一致,不过根据官方说明支持音乐远端播放以及AirPlay协议和DLNA协议(官方说明)。 5 DLNA技术和AirPlay技术 5.1 DLNA技术 DLNA(Digital Living Network Alliance)是由Sony、Intel、Microsoft等发起成立的一个认证组织,

31、其目的也是实现消费电子产品通过有线/无线网络实现设备互联、数据互通。相比于Miracast认证项目,DLNA有着自己的一套框架和相应标准:首先DLNA将市场上几乎所有的电子产品进行了分类(图30),一方面可以便于DLNA对众多的设备进行规范认证,另一方面也是DLNA为不同设备间进行交互制定标准的基础。 图30 DLNA定义的设备类别和类型 其次DLNA定义了设备工作架构(图31),其中UpnP是实现设备设备发现、连接、控制的重要协议层(参考文章),而媒体数据的传输则是使用HTTP传输协议或者是RTP协议。 图31 DLNA系统架构图 5.2 AirPlay技术 AirPlay是苹果公司实现的在

32、苹果产品或是其认证产品之间传输媒体信息的一套解决方案。AirPlay技术可以实现产品之间自动地互相发现,并且轻松地互相传输音乐、图片及视频文件。 AirPlay以组播DNS(Multicast DomainName ServermDNS)协议和DNS服务发现(DNS Service Discovery,简称DNS-SD)协议为基础,它们是IETFn Zeroconf工作组提出的用于自动寻找设备及服务的网络协议,苹果公司以这两个协议为基础,实现了苹果公司数字家庭网络框架。 AirPlay协议消息发送格式及规则基于mDNS协议,mDNS协议基于组播技术,定义了家庭各个设备之间的消息的基本格式和接收

33、/发送规则。该协议以DNS协议为基础,并对其消息格式和消息收发顺序作出了一些修改。例如对DNS消息包头进行了简化,使其专注于实现家庭设备的互相发现;另外,考虑到使用组播技术,mDNS在降低网络拥塞和消息冗余方面也作出了很多改进,使得局域网内设备和服务的发现不会引起过多的消息交互。 在mDNS协议的基础上,DNS-SD协议规定了一个服务宣告及使用的完整过程。即设备必须发送什么样的mDNS消息才能完整地宣告并描述自己服务。DNS-SD协议使用PTR、SRV和TXT三种类型的记录全面描述了一个服务的类型,名称以及所在主机的IP和端口号等。 当使用DNS-SD协议实现了对设备及服务的发现和描述后,苹果公司的AirPlay协议规定了图片、音频及视频的传输和控制消息格式,从而实现了智能设备之间的媒体共享和协同动作。在通过DNS-SD获得了其他设备及服务的信息之后,AirPlay使用HTTP消息实现了图片和视频的传输及控制,使用RSTP协议实现了音频的传输和控制 AirPlay工作模型和WiFiDisplay技术和DLNA技术基本一致,只不过它是苹果公司的私有方案,因此没有公开的规范资料(非官方协议协议标准)。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号