一、概述
1.1 简介
Miracast是由Wi-Fi联盟于2012年所制定，以Wi-Fi直连（Wi-Fi Direct）为基础的无线显示标准。支持此标准的消费性电子产品（又称3C设备）可透过无线方式分享视频画面，例如手机可透过Miracast将影片或照片直接在电视或其他设备播放而无需任何连接线，也不需透过无线热点（AP，Access Point）。
Wi-Fi Display（WFD）经常和Miracast联系在一起， Miracast实际上是Wi-Fi联盟对支持Wi-Fi Display功能的设备的认知名称。通过Miracast认证的设备将在最大程度内保持对Wi-Fi Display功能的支持和兼容。
1.2 架构介绍
图1.1 Miracst架构及协议栈
Miracast整体架构及协议栈从下到上为整体架构，包括：网络协议栈、流媒体传输协议栈、媒体封装协议栈、媒体加密协议栈、媒体编解码协议栈；从左至右为关键流程，主要包括WifiP2P发现及建连流程、RTSP媒体协商协议及流程、UIBC反控流程、编码打包发送等。
1.3 场景
作为目前主流投屏协议，WFD覆盖TV、PC、PAD、车机、电视盒子等用户投屏场景。按功能划分，支持WFD的设备分为WFD Source、WFD Primary Sink和WFD Second Sink。场景模型如下：
图1.2 音频流
图1.3 视频流
图1.4 音视频流
图1.5 多路流（一路视频&一路音频）
二、规格特性
2.1 功能特性
WFD支持的功能特性如下表所示：
注：M 代表Mandatory，O代表Optional
M特性代表WFD必须支持能力，O特性代表WFD可以选择支持的能力，在协商阶段来进行能力界定。
2.2 音频规格
WFD支持的音频编码格式如下表所示：
音频能力默认支持LPCM-2，48ksps 16bit，如果对端支持多种音频格式，可以在代码中设定优先级(AAC > LPCM)来决定使用何种编码方式。
2.3 视频规格
H264 CBP为必选，支持的分辨率范围：
27种 CEA格式，分辨率从640*480到4096*2160，帧率从24到60;
32种VESA格式，分辨率从800*600到2560*1600，帧率从30到60;
12种手持设备格式，分辨率从640*360到960*540，帧率从30到60;
WFD支持的视频规格如下表所示：
Sink端在回复M3指令时告诉Source端自身支持的属性及能力，Source端解析收到的信息，选择合适的分辨率、帧率等信息。发送给Source，完成视频格式的协商。
2.4 R2特性
R2是Wi-Fi Display Technical SpecificationV2.0的简称，兼容R1特性以外，增加了部分M&O的新特性，Sink端PC以及部分TV已支持R2部分特性。如下表所示：
三、关键技术
3.1设备搜索发现
WFD设备发现AOSP JAVA层业务逻辑主要步骤如下：
图3.1 WFD设备搜索发现
WifiDisplayAdapter通过WifiDisplayController发起
WifiDisplayController更新scan状态后调用WifiP2pManager的discoverPeers
WifiP2pManager通过WifiP2pService调用到Wifi子系统的p2pFind
WifiDisplayController逐层收到onSuccess回调后发起requestPeers请求
WifiP2pService获取到peers后通过onPeersAvaliable回调调用到WifiDisplayController
WifiDisplayController创建wifiDisplay并更新到mDesiredDevice
3.2 能力协商&会话建立流程
图3.2 WFD能力协商&会话建立流程
如上图所示，WFD Source端启动后，创建RTSP Server，等待WFD Sink端的连接，连接成功后Source端触发M1-RTSP Options请求，启动RTSP的交互流程
⚪M1~M4是能力协商流程：WFD Source查询WFDSink端的能力和WFD Source的能力进行匹配，选择双方都支持的最优格式，设置到Source编码器和本地播放引擎中，并通知到WFDSource端；协商是否启动UIBC，是否启用链路保护HDCP。协商的主要内容如下：
wfd-video-formats：video-format(H264/H265), profile,level,max-hres,max-vres,latency,min-slice-size,slice-enc-params,frame-rate-control-support
wfd-audio-codecs：audio-format(LPCM/AAC/AC3),modes(sample-rate/bit-depth/channel), latency
wfd-content-protection：hdcp2-spec（HDCP2.0/HDCP2.1）
wfd-client-rtp-ports：rtp-port0 RTP端口号
wfd_coupled_sink：coupled-sink-cap，sink-address
wfd-standby-resume-capability:standby-resume-cap("none"/"supported")
wfd2-aux-stream-formats:aux-codecs
wfd2-transport-switch:profile, mode=play, TCP/UDP切换
⚪ M5~M7是会话建立流程：能力协商完成后，source端发起Trigger Setup，完成端口协商，建立Socket连接，开始音视频流采集编码打包发送。
⚪ M8是关闭流程：会话建立成功后，source和Sink端都可以发起TEARDOWN流程。
3.3 传屏控制
图3.3 WFD传屏流程
⚪ Pause/Play流程，会话建立后可以触发
⚪ 音频路由切换流程，RTSP-M10携带的内容
wfd-route：destination (primary/secondary)，音频可在Primary WFD和Secondary WFD之间切换。
⚪ 连接设备变更流程，RTSP-M11携带的内容
wfd-connector-type: connector-type(0:VGA/1:S-Video/2:Composite/5:HDMI)
⚪ Standby流程
Source端或Sink端进入Standby时，向对方发送M12消息。发送内容携带 wfd_standby。
⚪ IDR请求流程
IDR流程由Sink端发起，可在花屏或卡顿后触发。Source端收到IDR请求之后，将所有的参考帧队列丢弃，重新从I帧开始发送数据。
⚪ 保活流程
收到M7 PLAY请求后，开始启动保活流程，周期性检测Sink端是否在线，每隔5秒检查一次。
3.4 UIBC反控
图3.4 WFD UIBC
UIBC协商过程由Source端发起，询问Sink端的UIBC能力，收到Sink端回复能力集后，创建UIBCServer进行监听，等待Sink端的UIBC连接，同时发送M4消息等待协商完成。
当Sink端的UIBC能力变更时，如增加接入遥控器/键盘/鼠标，可通过M14-RTSP消息通知source端。
source端可以通过M15消息主动打开关闭UIBC。
四、代码示例
4.1 P2P扫描流程
用户点击手机投屏时进入到WiFiDisplaySetting界面，会调用到对应的onCreate和onStart方法，在onStart()方法中，首先注册ACTION_WIFI_DISPLAY_STATUS_CHANGED的receiver，这个broadcast会在WifiDisplayAdapter里面当wifi display的状态发生改变时发送，包括扫描到新的设备、开始连接、连接成功、断开等消息都会被这个receiver接收到。
MediaRouter通过updateDiscoveryRequest去更新是否需要发送Discovery request从而执行startWifiDisplayScan，该函数最终调用到WifiDisplayController中执行updatecanState进行设备扫描。
4.2 P2P连接流程
当扫描到可用的设备后，就会显示在WifiDisplaySettings这个页面上，当我们点击选择其中一个设备后，就会触发connectWifiDisplay开始P2P的建立。参考代码如下：
connectWifiDisplayInternal通过handler发送处理消息到WifiDisplayController中requestConnect方法，该方法通过updateConnection来发起连接。参考代码如下：
onSuccess()并不是表示P2P已经建立成功，而只是表示这个发送命令到wpa_supplicant成功，所以在这里设置了一个连接超时30秒。当连接成功后，会发送WIFI_P2P_CONNECTION_CHANGED_ACTION的广播出来，当WifiDisplayController收到该广播后，会调用handleConnectionChanged来获取当前P2P Group相关的信息，如果获取到的P2P Group信息里面没有连接的设备（mConnectingDevice）或者需要的设备（mDesiredDevice）的信息，则表示连接出错了，直接退出。
如果当前连接信息与前面设置的mConnectingDevice一致，则表示连接P2P成功，这里首先会移除前面设置的连接timeout的callback，然后设置mConnectedDevice为当前连接的设备，并设置mConnectingDevice为空，最后调用updateConnection来更新连接状态信息。
4.3 RTSP连接建立
P2P建立成功后，会走到WIfiDisplayController中的updateConnection方法
在listen方法中会去创建一个RemoteDisplay对象，并调用startListening。参考代码如下：
nativelisten通过JNI去到networksession中创建RTSP服务。参考代码如下：
RTSP服务创建好后，等待client端进行连接，进入媒体能力协商阶段。
4.4 视频流获取
视频流有两种方式获取：
一种方式通过mediacode createInputSurface接口创建surface给virtualdisplay，SurfaceFlinger每次合成一帧时会通知到mediacode进行编码。WFD只需要通过dequeueOutputBuffer来获取编码后的数据即可。参考代码如下：
另一种方式WFD创建bufferqueue 将producer传递给virtualdisplay，SurfaceFlinger每次合成一帧的时候通知WFD，WFD 通过consumer取合成后的数据进行编码。通过该方式WFD可自行控制帧率。参考代码如下：
4.5 音视频打包
在WFD流媒体传输中，编码后的音视频基本码流ES首先打包成PES，在PES包中加入PTS跟DTS等时间戳信息，一个大的PES包拆成一系列188个字节长度的传输包(TS Packet)，在传输包中加入定时信息PCR和节目专用信息PSI，最后将TS Packet打包为一个RTP，每个RTP再打包为一个UDP。其中打包RTP的方法就是在MPEG-TS数据前面加上RTP Header，而打包UDP的方法就是在RTP数据前面加上UDP Header。参考代码如下：
五、总结
本文从概念、场景、功能特性、音频规格、视频规格以及关键技术等维度对WFD进行了详细介绍。并且以实际的案例代码对关键流程进行了解读，希望可以帮助大家了解WFD模块。
WFD基础框架的构建只是第一步，帧率、延时、音画同步、卡顿率、花屏率等用户体验指标才是做好WFD关键。由于WFD 涉及Andriod框架多个模块(WMS/DMS/SurfaceFlinger/Audio/Video/WiFi等)，需要对各个模块深入挖掘才能持续提升用户体验。
参考文献：
1. AOSP WFD https://android.googlesource.com/platform/frameworks/av/+/android-4.2.2_r1.2/media/libstagefright/wifi-display/source/
2. Wi-Fi Display Technical SpecificationV2.2: https://www.wi-fi.org/discover-wi-fi/miracast
3. https://www.digital-cp.com/sites/default/files/HDCP%20Interface%20Independent%20Adaptation%20Specification%20Rev2_3.pdf
4. AOSP Andriod http://aospxref.com/android-13.0.0_r3/
往
期
推
荐
欢迎赐稿 2023 中国 Linux 内核开发者大会及报名线下参会
一文了解Vulkan在移动端渲染中的带宽与同步
AMD高保真超分算法1.0解密
长按关注内核工匠微信文章来源：https://www.toymoban.com/news/detail-818212.html
Linux内核黑科技| 技术文章| 精选教程文章来源地址https://www.toymoban.com/news/detail-818212.html
到了这里，关于手机投屏之WFD简介的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
