Overview and Technical Details of Miracast (Wi‑Fi Display) with Implementation Examples

1. Overview

Miracast is a wireless display standard defined by the Wi‑Fi Alliance in 2012, based on Wi‑Fi Direct. Devices that support the standard can stream video and photos from a source (e.g., a smartphone) to a sink (e.g., a TV) without cables or a Wi‑Fi hotspot.

Wi‑Fi Display (WFD) is the generic term for the technology; Miracast is the Alliance’s branding for devices that fully support WFD.

1.2 Architecture

The Miracast architecture consists of several protocol stacks from bottom to top: network protocol stack, media transport stack, media container stack, media encryption stack, and media codec stack. Key processes include Wi‑Fi P2P discovery and connection, RTSP media negotiation, UIBC reverse‑control, and encoding/packetization.

1.3 Scenarios

WFD covers a wide range of casting scenarios such as TV, PC, tablet, automotive head‑units, and set‑top boxes. Devices are classified as WFD Source, Primary Sink, or Secondary Sink.

2. Specification Features

Features are marked as Mandatory (M) or Optional (O). The specification defines audio codecs (LPCM‑2, AAC, etc.) and video codecs (H.264, H.265) with various resolution and frame‑rate ranges (e.g., 27 CEA formats from 640×480 to 4096×2160, 24–60 fps).

2.4 R2 Features

R2 (Wi‑Fi Display Technical Specification V2.0) adds new M and O features while remaining compatible with R1.

3. Key Technologies

3.1 Device Discovery

The AOSP Java layer performs discovery via WifiDisplayAdapter → WifiDisplayController → WifiP2pManager.discoverPeers → WifiP2pService.p2pFind, followed by callbacks that deliver the list of peers.

3.2 Capability Negotiation & Session Establishment

The source creates an RTSP server, receives M1‑M4 messages to negotiate video/audio formats, content protection (HDCP), UIBC support, and transport parameters. After negotiation, M5‑M7 establish the session, and M8 handles teardown.

3.3 Screen Control

Control messages include pause/play, audio route switching (wfd‑route), connector type changes (wfd‑connector‑type), standby (M12), IDR request for error recovery, and keep‑alive checks.

3.4 UIBC Reverse Control

The source initiates UIBC negotiation, creates a UIBC server, and can receive remote input (keyboard, mouse, remote controller) via M14/M15 messages.

4. Code Examples

4.1 P2P Scan Process

When the user initiates casting, the Wi‑Fi Display settings register a broadcast receiver for ACTION_WIFI_DISPLAY_STATUS_CHANGED, which reports scan results, connection attempts, and disconnections.

4.2 P2P Connection Process

Selection of a discovered device triggers connectWifiDisplay, which sends a request to WifiDisplayController. The controller updates the connection, handles time‑outs, and processes Wifi‑P2P connection change broadcasts to confirm successful group formation.

4.3 RTSP Connection Setup

After P2P is established, WifiDisplayController creates a RemoteDisplay object and starts an RTSP server via native listen calls (JNI) that instantiate a network session.

4.4 Video Stream Acquisition

Two methods are shown: (1) using MediaCodec.createInputSurface with VirtualDisplay, where SurfaceFlinger notifies MediaCodec of each frame; (2) using a BufferQueue supplied to VirtualDisplay, allowing the WFD module to control frame rate.

4.5 Audio/Video Packaging

Encoded ES streams are packed into PES, then into MPEG‑TS packets (adding PCR/PSI), then encapsulated in RTP, and finally sent over UDP. The code demonstrates header insertion for each layer.

5. Conclusion

The article provides a comprehensive overview of Miracast/WFD concepts, specifications, and implementation details, emphasizing that building a robust WFD solution requires deep knowledge of Android subsystems (WMS, DMS, SurfaceFlinger, Audio, Video, Wi‑Fi) and careful tuning of performance metrics such as latency, frame rate, and synchronization.

References

1. AOSP WFD source code 2. Wi‑Fi Display Technical Specification V2.2 3. HDCP Interface Specification Rev 2.3 4. AOSP Android source