1 WiFiDisplay简介
1.1WiFiDisplay概述
WiFiDisplay(WFD)是WiFi联盟在已有技术的基础上，为了加速视/音频的传输分享而提出来的一个新概念。WiFi联盟对此成立了一个认证项目：Miracast-- 用来认证一个设备是否支持WiFiDisplay功能。
下图是WiFiDisplay功能的技术支撑体系，实际上最重要的部分就是WiFi Direct：也就是两个设备无需AP(AccessPoint)的情况下直接相连，这就奠定了两个带WiFi功能的设备能够随时传递高质/高清视频的前提。另外，其他深蓝色的技术是必须支持的：
11n：即802.11n协议，支持最高传输速度540Mbit/s；
WMM：即WiFi Multimedia的简称，主要针对不同的数据内容保证其传输的稳定和质量；
WPA2：是WiFi联盟对于采用802.11i协议并采用更为复杂加密算法的认证项目；
WiFi ProtectedSteup：也是一个WiFi联盟的一个认证项目：简化用户安装无线局域网和对安全性能的配置工作；
WiFi Direct：表示设备可以实现直接互联，无需AP的参与；
WiFi Miracast：即为是否可以实现wifi-display功能的认证项目。
图 1 WiFiDisplay技术支撑架构
另外，WiFi联盟还描述了WiFiDisplay的简化工作模型(图2)。在这个工作模型中，Miracast定义传输视/音频数据的一方为source端；接受数据并重新呈现的为sink端。从图中可以看到，source端要有数据内容的存储和下载/生成能力；对数据进行编码能力。而sink端则需要对数据的解码能力；对视/音频进行再度呈现的能力。而Miracast则是定义了这两个设备之间，怎样保持会话；可以传输数据的格式标准；会话控制等内容。
图 2 WiFiDisplay的工作模型
WiFiDisplay重要规范及标准
WiFi联盟定义了Miracast支持的视/音频格式标准：
图 3 Miracast支持的显示、视频、音频格式标准
同时，Miracast也规范了设备连接后进行协商(图4)、建立会话的流程(图5)。详细描述了设备在建立物理连接后，通过标准步骤来完成WiFi Display的会话建立，然后开始数据传输。关于各个标准步骤的详细信息，请见Miracast官方解释。
Miracast定义的设备协商标准过程
Miracast定义的显示会话建立过程标准
主要模块介绍
由于WFD功能主要涉及wifiP2P功能和display功能，现对Android中涉及的两个模块wifiP2pService和SurfaceFlinger做一些介绍。
WiFiP2P简介
WiFiP2P是WiFi联盟提出的一项重要技术规范，它定义了两个wifi设备如何在没有路由的情形下连接并通信。根据定义，支持WiFiP2P的设备需要扮演P2P GroupOwner或P2P Client角色来形成一个P2P Group：
WiFiP2P工作组模型
其中P2P Group Owner的设备需要发挥传统路由的功能：控制WiFiP2P工作组，使能设备通信等；P2PClient设备则需要连接上P2P Group Owner设备来形成一个工作组来通信。
在以上的工作模型基础上，WiFiP2P细化了以下技术项：
WiFiP2P定义的P2PDiscovery规范
在P2P Discovery规范中，定义了发现设备(Device Discovery )并构建工作组(GroupFormation )的细节。其中发现设备规定设备首先进入扫描阶段(ScanPhase)，去发送Probe Request帧；然后进入寻找阶段(Find Phase)，在这个阶段中设备会在SearchState和Listen State中切换：两个阶段分别是发送Probe Request帧、监听ProbeRequest帧并发送Probe
Response帧。当找到附近的P2P设备后，就可以来构建一个工作组：包括决定谁是Group Owner的协商(GONegotiation )和设备交换安全配置信息(Provisioning)，用于Client设备利用安全配置信息连接GO。
另外，WiFiP2P还定义了GroupOperation技术项，具体描述了和工作组交互的场景和流程：
·P2P Device Join GO(Group Owner)
·P2P Device Join GC(Group Client)
·GC invite P2P Device
·GO invite P2P Device
Android中WiFiP2P
Android中关于WiFiP2P模块主要涉及以下几个部分：
Android中WiFiP2P涉及模块
WiFiP2PSettings 是用来和用户交互的部分，主要是提供UI给用户选择打开/开闭WiFiP2P功能、呈现搜寻到的P2P设备给用户等；WiFiP2PSettings实现的功能调用的是WiFiP2PManager中的接口；WiFiP2PManager最终会与WiFiP2PService交互，它们依靠Android的Binder机制来实现进程间的通信，WiFiP2PService则是用来管理Android中WiFiP2P功能的核心模块：
Android中WiFiP2P涉及模块
在WiFiP2PService类中有一个内部类P2pStateMachine(状态机)用来管理WiFiP2P的不同状态然后执行不同的操作；另外WiFiP2PService还会创建一个WifiMonitor对象用于接收来自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是一个开源项目，实现了WiFi联盟规范中的众多功能，详见。下图是wpa_supplicant及与下层部件的一个草图：
wpa_supplicant及底层部件草图
SurfaceFlinger
总所周知，SurfaceFlinger是Android中对图形画面进行管理并交由FrameBuffer实际显示的重要模块，它需要收集系统中所有应用程序绘制的图像数据，然后集中处理后显示到物理屏幕上。下图是Android下图形显示的一个简略框图：
Android显示系统简略框图
上图描述的是使用OpenGL ES图形开发规范下的情况。首先，每个应用程序在自己的窗口上进行绘图，这里的窗口(Window-2)实际上对应的是一些缓冲区；然后SurfaceFlinger则会对这些缓冲区进行统一管理；最后每一帧的图形数据会被送到FrameBuffer上并实际显示在设备上。
对于上层应用来说，Window-2在Android中的实现为SurfaceTextureClient类。由于是在OpenGL ES的开发框架下，SurfaceTextureClient实际上是继承自ANativeWindow同时在本地实现了一些接口(参见EGL知识)：
上层应用的window实现
hook_dequeueBuffer()和hook_queueBuffer()是框架定义中需要实现的本地函数，上层应用作图时需要从缓冲队列得到缓冲区；作图完成后需要把缓冲区送还给缓冲队列。具体情形如下：
本地窗口和缓冲队列交互图
如上图，本地窗口实际上是从BufferQueue来得到缓冲区；画图后再将缓冲区入列到缓冲队列。而BufferQueue是在应用程序创建Surface(在SurfaceFlinger端对应Layer)的时候生成的，本地窗口通过返回的ISurface对象得到ISurfaceTexture对象来最终和BufferQueue交互。
对于SurfaceFlinger侧的本地窗口Window-1(图11)来说，SurfaceTextureClient也是作为本地窗口的功能。不过在SurfaceFlinger端通过标准的OpenGL ES接口进行请求缓冲区操作和入列缓冲区操作的对象就不一样了；而且在入列缓冲区后所进行的操作也不一样：
图14 SurfaceFlinger的本地窗口
如上图，在SurfaceFlinger端的本地窗口Window-1，会有自己的BufferQueue对象，而最终和HAL层的Gralloc模块交互实际分配缓冲区的时候，会根据功用不同来分配不同类型的缓冲区：上层应用分配的缓冲区是给OpenGL绘图用的；SurfaceFlinger这边分配的缓冲区是要送显FrameBuffer的(详见gralloc.h中定义)。
对于上层应用来说，填充好缓冲区后处理端(consumer&producter模型)会调用到Layer文件的onFrameQueued()函数，如果需要渲染图形这时候需要等待一个VSYNC信号(详见Android的Project Butter)，收到VSYNC信号后会对需要渲染的Buffer按照Z轴计算可见区域并进行图像混合；而对于SurfaceFlinger端来说，缓冲区入列后consumer会最终调用fb的HAL层接口完成实际显示。
Android下实现详述
Android自从4.2后就支持WiFiDisplay功能了。以下是Miracast官方公布的WFD工作模块框图：
图15WiFiDisplay的工作模块框图
在以上工作模型的基础上，Android主要做了以下工作：
·新加了WiFiDisplay的setting部分，用来为用户提供操作选项；
·新加DisplayDevice类用来描述不同的显示设备，WiFiDisplay作为一个虚拟显示设备；
·修改了SurfaceFlinger模块来支持WiFiDisplay，通过SF把显示内容投放到不同的设备上；
·新加了DisplayManagerService来对系统的显示设备进行统一管理
·根据Miracast规定的会话建立管理流程，实现了source端和sink端的程序
应用程序端
对于WiFiDisplay功能，Android提供了相应接口给应用程序使用，以实现在第二显示设备上进行显示。具体内容参考，其中关键步骤见图16：
图16 Android上WFD应用编程简要步骤
可以看到主要包括Presentation和MediaRouter两个class。实际上它们都会调用一个重要的class提供的功能 – DisplayManager，而DisplayManager接口的具体实现在另外一个进程中的DisplayManagerService.java文件中。
DisplayManagerService及相关
DisplayManagerService是Android中管理WiFiDisplay功能的核心服务：
DisplayManagerService简图
每一种显示设备(LocalDisplayDevice、WiFiDisplayDevice)都有一个对应的DisplayAdapter，DisplayManagerService通过管理这些Adapter来管理不同的显示设备。比如DisplayManager发起的对WiFiDisplay的操作请求，都会由DisplayManagerService转给WifiDisplayAdapter来实际完成。另外DisplayManagerService服务还通过WindowManagerFuncs窗口管理功能接口直接调用WindowManagerService的函数，实现窗口内容的刷新；同样DisplayManagerService服务还通过InputManagerFuncs接口直接调用InputManagerService的函数，用来设置输入系统需要的显示器的显示视图信息。
而WifiDisplayAdapter的操作最终会实现在WifiDisplayController中，去实现设备扫描、设备连接等操作：
WifiDisplayController简图
关于和其他设备的WiFiDirect连接，Android有专门的一个WifiP2pService来管理，这里对于设备的连接就是直接调用WifiP2pManager(和WifiP2pService交互)所提供的接口来完成。
Source/Sink设备会话管理端
在设备建立WiFi连接后，会在RemoteDisplay上监听RTSP的连接，用于后续创建session和传输实时流数据。
监听RTSP连接流程简图
如上图，实际的监听最终流程会走到RemoteDisplay中，即一个RemoteDisplay对象的创建。通过创建这个本地的RemoteDisplay对象将会创建一个ANetworkSession对象，用于管理网络部分的操作；创建一个ALooper对象，实现各类消息的派发和处理；创建一个WifiDisplaySource对象(由于搭载Android系统的大多数设备在WiFiDisplay场景中，多数会扮演source端的角色，因此这里创建的是WifiDisplaySource对象)，具体处理各类消息：
RemoteDisplay简图
另外，Source目录还包括PlaybackSession.cpp、MediaPuller.cpp、Converter.cpp、TSPacketizer.cpp、Sender.cpp等C++类文件和相应的头文件，分别负责Source端的会话过程管理、镜像媒体读取、编码、TS打包及RTP打包发送等过程。Converter 对象中包括一个MediaCodec对象具体负责编码过程，MediaCodec对象实际通过ACodec对象调用IOMX接口使用OPENOMX媒体框架完成镜像数据的编码。
视/音频数据获取方式
source端的媒体数据获取简图
如图，source设备端程序对要在远端设备进行呈现的视/音频数据通过MediaSource类进行管理。上图中的SurfaceMediaSource和AudioSource都是继承自MediaSource类，它们分别对应视频数据和音频数据，根据不同的情景，source设备端程序可以添加视频或者音频数据源到当前程序中来，而且每一个MediaSource会对应创建一个Converter对象和一个MediaPuller对象，用于媒体数据的编码和数据读取等操作。下图是获取视频数据的程序片段，调用MediaSource的通用接口read来实现。
获取视频数据程序片段
视频数据源
由图22可知，视频数据是从一个BufferQueue中读取的。上层应用正是将需要显示的视频数据放到和这个BufferQueue对应的Surface中，实现视频数据的远端设备投递。
SurfaceFlinger管理不同显示设备简图
较详细来说，上文中的surface是由WiFiDisplayDevice所持有的，这部分内容还和SurfaceFlinger为支持画面投递到不同的设备上而进行的改动有关。如图23，主要是抽象了DisplayDevice来表述本地显示设备和WiFiDisplay等显示设备，在SurfaceFlinger.cpp的handleTransactionLocked函数中可以看到：
图24 SurfaceFlinge对不同显示设备处理代码片段
对于virtualDisplay的话(WiFiDisplay设备)，mFramebufferSurface为空；SurfaceTextureClient直接使用了State信息中携带的surface变量。这个Surface正是当RTSP建立后，在回调函数onDisplayConnected中注册到SufaceFlinger中的(3.3节描述监听连接)，这样SurfaceFlinger会将上层应用的显示数据投递到这个Surface上面，而source端的程序则会从这个surface上取出数据。
音频数据源
由图21可以看到，音频数据的获取是通过AudioRecod来得到。Android系统对于Audio系统抽象了AudioTrack对象和AudioRecord对象来分别用于音频数据的输出和音频数据的采集/获取。对于WiFiDisplay情景下的音频数据处理，Android也是在不破坏原有架构的情况进行的：
图25 WFD情景下音频简单架构图
AudioRecord通过AudioSystem对象来获得AudioFlinger和AudioPolicyService的远端接口进行操作，最终和HAL层的module交互，实际上完成的是从一个管道中的读取操作；而AndroidTrack也是基于同样的模型，只不过流程相反，完成的是向HAL层的一个对应管道中的写操作。其中AudioPolicyService在Android关于Audio的各个组件中扮演着核心角色：
AudioPolicyService核心与其他组件交互图
如上图，详细来说：AudioPolicyService直接交互的是一个称为‘POLICY’的HAL层模块，这个模块提供了通用接口；然后通用接口会调用到一个具体的策略管理类中提供的接口，对应上图的AudioPolicyManagerALSA；最终，会根据不同的调用参数来获取真正的HAL层模块，和硬件交互，而AudioFlinger得到具体的HAL层模块后，就可以直接对其操作了。
这些具体的HAL模块，ID名称都为AUDIO_HARDWARE_MODULE_ID ，只是被编译成了不同名称的库文件，而对应于WiFiDisplay的HAL层模块不需要和具体的硬件打交道，实际实现为一个管道：
WiFiDisplay的HAL模块程序片段
因此，对于需要通过WiFiDisplay到远端设备进行呈现的音频数据，只需要使用AudioTrack的接口来把音频数据放到上文HAL模块中的管道；而WiFiDisplay的source程序端也只需要调用AudioRecord的接口取出数据即可。最发送前的编码，音频/视频打包则专门去处理，不破坏原有的系统架构。
4 WiFiDisplay应用场景及相关产品
主要应用场景
WiFiDisplay技术实现视/音频数据的无线远端呈现，目前涉及视/音频数据处理的设备较多，常用的应用场景有：
1、数字播放器和数字电视工作场景：在这个应用场景下，由于source端设备不具有用户交互屏幕，因此sink端设备需要和用户交互完成设备的配对、传输的控制等工作；
图28 WFD应用场景1
2、下图描述的是一个数字机顶盒和DTV加上一个AP的工作模型，source设备在这个模型中同时连接到AP和sink设备，source端的数据此时是从网络获取的。这在WiFiDirect模型中是允许的，对于P2P连接在底层实际上对应的一个虚拟地址。
图28 WFD应用场景2
3、下图是描述的是有两个sink端设备的应用场景，此时source设备需要发现和连接两个sink设备，并发送视频/音频数据到不同的sink设备上。同时两个sink设备也需要彼此通信，来做同步和其他信息交换。
图28 WFD应用场景3
相关应用产品
WiFiDisplay的应用产品，市场上已经有一些，比如百度推出的百度影音棒、小米盒子等。其中百度影音棒的工作情况如下：()
百度影音棒2S工作简图
百度开发出的百度影音棒系列，实际上一种充分考虑现实情况的一套无线视频播放方案。由上图可知，考虑到现有电视的实际情形(大多数只带HDMI功能)，这套方案对于TV还是使用HDMI和BaiDu 2S有线连接，而真正的无线模块则是这里的BaiDu 2S。这里的source设备即为手机，sink端设备其实就是BaiDu 2S。
小米盒子和上图的工作模型基本一致，不过根据官方说明支持音乐远端播放以及AirPlay协议和DLNA协议()。
DLNA技术和AirPlay技术
DLNA(Digital Living Network Alliance)是由Sony、Intel、Microsoft等发起成立的一个认证组织，其目的也是实现消费电子产品通过有线/无线网络实现设备互联、数据互通。相比于Miracast认证项目，DLNA有着自己的一套框架和相应标准：首先DLNA将市场上几乎所有的电子产品进行了分类(图30)，一方面可以便于DLNA对众多的设备进行规范认证，另一方面也是DLNA为不同设备间进行交互制定标准的基础。
DLNA定义的设备类别和类型
其次DLNA定义了设备工作架构(图31)，其中UpnP是实现设备设备发现、连接、控制的重要协议层)，而媒体数据的传输则是使用HTTP传输协议或者是RTP协议。
图31 DLNA系统架构图
AirPlay技术
AirPlay是苹果公司实现的在苹果产品或是其认证产品之间传输媒体信息的一套解决方案。AirPlay技术可以实现产品之间自动地互相发现，并且轻松地互相传输音乐、图片及视频文件。
AirPlay以(Multicast DomainName Server—mDNS)协议和(DNS
Service Discovery，简称DNS-SD)协议为基础，它们是提出的用于自动寻找设备及服务的网络协议，苹果公司以这两个协议为基础，实现了苹果公司数字家庭网络框架。
AirPlay协议消息发送格式及规则基于mDNS协议，mDNS协议基于组播技术，定义了家庭各个设备之间的消息的基本格式和接收/发送规则。该协议以DNS协议为基础，并对其消息格式和消息收发顺序作出了一些修改。例如对DNS消息包头进行了简化，使其专注于实现家庭设备的互相发现；另外，考虑到使用组播技术，mDNS在降低网络拥塞和消息冗余方面也作出了很多改进，使得局域网内设备和服务的发现不会引起过多的消息交互。
在mDNS协议的基础上，DNS-SD协议规定了一个服务宣告及使用的完整过程。即设备必须发送什么样的mDNS消息才能完整地宣告并描述自己服务。DNS-SD协议使用PTR、SRV和TXT三种类型的记录全面描述了一个服务的类型，名称以及所在主机的IP和端口号等。
当使用DNS-SD协议实现了对设备及服务的发现和描述后，苹果公司的AirPlay协议规定了图片、音频及视频的传输和控制消息格式，从而实现了智能设备之间的媒体共享和协同动作。在通过DNS-SD获得了其他设备及服务的信息（即设备或服务的IP地址及端口号）之后，AirPlay使用HTTP消息实现了图片和视频的传输及控制，使用RSTP协议实现了音频的传输和控制
AirPlay工作模型和WiFiDisplay技术和DLNA技术基本一致，只不过它是苹果公司的私有方案，因此没有公开的规范资料()。
PDF下载：http://download.csdn.net/detail/srw11/7645371
如何实现WiFi Display互联：我的一次WiFi Display（Miracast）功能发送端（source）和接收端（sink）的实现笔记
公司业务需要在安卓车载产品和手机端实现WiFi Display（Miracast）功能，可能是最近浪的比较久，这项任务最终指派给了我，公司是衣食父母嘛有任务义不容辞。周一接到任务夸下海口一周内完成，周...
Android 4.2wifidisplay采集
http://www.cnblogs.com/pengxinglove/p/5764126.html
Android 4.2wifidisplay采集
Android 4.2wifidis...
摆脱某某助手，使用无线投屏功能共享安卓屏幕到PC
过去为了方便的把手机屏幕投射到电脑上，使用过Teamviewer，ApowerMirror等软件，但是速度和质量均不理想，也不是我想要的官方形式。
这里我要推荐的是Andoird系统自带的无线显示功能...
多屏互动技术研究（二）之WifiDisplay(Miracast)技术原理及实现
WifiDisplay(Miracast)技术原理及实现
WifiDisplay(Miracast)技术原理及实现
1. WifiDisplay简介
2. WifiDisplay协议流程
Android 4.2 上Wi-Fi Display(Miracast)的开启和使用 无线显示
Android4.2中包含有miracast功能。
Miracast是Wi-Fi Alliance于日宣布启动的Wi-Fi CERTIFIED Miracast(TM)认证项目。Mira...
android WifiDisplay 源码分析系列 （二）
JAVA层的分析，从扫描和连接说起。
关于WifiDIsplay的JAVA层的代码在“packages/apps/Settings/src/com/android/settings/wfd/Wif...
Android Wi-Fi Display（Miracast）介绍
推荐&em&下载&/em& wifidisplay软件&em&下载&/em& 5C币 74&em&下载&/em&
wifidisplay软件 5C币 74&em&下载&/em&
wifidisplay&em&下载&/em& 5C币 74&em&下载&/em&
&em&wifidisplay安卓&/em&版 5C币 39&em&下载&/em&
热门资源标签 android...
没有更多推荐了，　　WiFI Display（WFD）是WiFI Alliance 开发出的一种规范，使多媒体设备之间建立和维持一个基于WiFi的连接，并且利用这个连接推进视频/音频的在目标设备的呈现播放。
　　 Wi-Fi Display，手机/移动PC-电视/显示器将可以实现无线连接。该标准由WiFi无线产业联盟制定，还在测试中，技术可以压缩3D视频，从而通过Wi-Fi传输。3D视频很耗宽带，如果不压缩就会迟滞，Wi-Fi Display技术可以将延迟时间降到百分之一毫秒以下。
　　 Miracast实际上就是WiFi联盟（WiFi Alliance）对支持WiFi Display功能的设备的认证名称（该认证项目已经在2012年9月正式启动）。而通过Miracast认证的设备，便可提供简化发现和设置，实现设备间高速传输视频。
2 WFD建立和检测
（1）设备间建立WFD
1）必要的部件
　　这里所说的设备，是指有android系统的手机、平板、TV等，或者有HDMI口的TV。
　　设备间创建WFD是由2个设备来建立的，其中一个为发送端（Source），另一个为接收端（Sink）。 如下图所示为WFD的建立示意图。
2）使用无线传屏器同电视建立连接
　　1.将无线传屏器和电视使用HDMI线连接；
　　2.将电视打开，同时确保电视选择HDMI接入，而不是在其他接入方式；
　　3.使用micro-USB线给无线传屏器供电；
　　4.打开手机、平板或电脑的投射功能进行连接。
（2）测试Wifi Display（使用两台手机）
1）打开手机设置界面点击“显示” &
2）在显示界面点击投射 &
3）在投射界面点击右上方的图标 &
4）点击勾选“开启无线显示” &
5）在另一台手机进行上述同样的操作
6）打开此设备，让其他设备可检测到此设备&&
7）此时等待其他设备连接
8）此时另一台设备界面会有已打开设备的设备号，点击连接，第一台设备将收到建立连接的提示 & 9）点击“接收”，此时投射成功 &
3 WFD调试基础
（1）文件位置 在平台基线的base的Vendor/qcom/proprietary/下。
Kernel 中的WFD代码位于\kernel\drivers\media\platform\msm\wfd
（2）JNI的交互 在WFD代码中，WFD的实现是通过JNI同使用C/C++写的framework层和java写的API组成的。其控制流如下：
WFD app-&SessionManagerService.java(SM-A)-&WFDNative.java-&JNI Layer-&WFDNative.cpp-&Wifidislay.cpp-&SessionManager.cpp(SM-B)。
（3）WFD连接基础
　　WFD建立在wifi p2p连接基础上的，支持以下两种连接方式
1）wifi direct:（必须支持）
　　 设备无需通过无线路由器即可相互连接的技术，需要一台设备作为组织者建立一个类似ap功能的网络，其他设备可以搜索到并用wifi连接上
2）TDLS:（可选）
　　2台wifi设备连接在同一个Ap上，它们可以直接建立一个点对点的通道实现数据传输。 如下图所示为WFD建立的11个过程。
& 1.Device Discovery
　　wfd设备之间的搜索探测功能，使用现有的wifi p2p技术为基础，并在wifi信标、探测信号中加入了wfd特有格式的探测信号。
& 2.Service discovery
　　此功能是可选功能，也是建立在wifi p2p原有的servicediscovery基础上，并加入wfd特有格式的请求和回应命令。
&3.Device selection
　　 用户选择一个需要连接的设备，Wifi-direct 连接的强制和默认的，TDLS可选。若有2个sink，一级和二级sink，wifi p2p组织者必须是source。
4.Wifi connection setup
　　使用wifi direct和tdls技术，建立wfd基础线路。 将设备建立TCP连接，并创建一个控制端口来建立和维护session，该端口跑的协议是RTSP。
5.Display capability negotiation
　　参数协定，决定需要使用的最佳参数，包括音视频解码率、分辨率、信道负载等等。
　　若有一级和二级sink存在，都需要单独设定。
　　过程和命令如下图。
　　 setup user input back channel，用户输入反向通道，此功能是可选的。
　　有两种类型：1）generic：硬件无关型，如鼠标点击，按键点击、touch点击、放大缩小等。 2）HIDC人机接口设备控制：包括红外线、USB、蓝牙、WIFI、游戏杆、遥控器等。
7.Link content protection
　　 建立内容保护机制，可选功能。采用的是HDCP2.0安全协议，需要在数据流传输前建立。 8.WFD Session setup
　　WFD核心步骤，必须在能力协定的基础上建立。建立过程使用RTSP通信，具体见下图。
9.AV Streaming
　　先将Audio和video多路复用成一个MPEG2传输流。
　　在传输流头部用MPEG2-TS格式打包，并封装RTP、UDP、IP报头如下图。
10.Payload control capability
　　在数据流建立之后，需要有控制管道负载的能力，包含以下功能： 1）时间同步& 如果有2个sink设备，二者音视频必须同步，实现保真。2）编码速率控制：因信道条件和电源管理优化控制管道负载。
11.Display Session Teardown
　　WFD会话终止，按连接分两种方法：
　　　　1）Wifi-direct：跟 wifi p2p规范一样，source和sink有序拆除连接。
　　　　2）TDLS： IEEE P802.11z specification规范动作，有序的拆除终止连接。
阅读(...) 评论()