手机投屏之WFD简介

一、概述

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解密

长按关注内核工匠微信

Linux内核黑科技| 技术文章| 精选教程