By Paul Ferrill and Steve Barile
Using more than one screen is becoming commonplace for watching videos, playing games, sharing pictures, and even business uses, including Microsoft PowerPoint* presentations. But how users access that second screen varies by device and operating system.
This article looks at the differences among the top three technologies—Apple AirPlay*; Google Chromecast*; and the Wi-Fi Alliance's Miracast*, which includes Intel® Wireless Display (Intel® WiDi)—outlining the advantages and disadvantages of each from a developer’s point of view.
As primary devices become smaller, the preferred display sizes have become larger. By looking at two early use cases (a small device wirelessly displaying its screen contents on something larger and a smart TV displaying Internet content), you can see how the split between proprietary and open standards came about. Each technology I discuss here approached the challenges from a different starting point, and each gained market share with different operating systems, devices, and focus.
Wi-Fi Alliance's Miracast* & Intel® Wireless Display
Miracast is not a device or software but rather the name of the technology described by the Wi-Fi Alliance specifications. It is not an application, although you’ll often hear the term Miracast app to describe this functionality. Briefly, the Miracast spec defines how to send MPEG4 (H.264) video from a source device to a sink device via peer-to-peer networking using a Wi-Fi Direct* (802.11) connection. The specification describes how connections are established using a prescribed series of steps.
Both the source and sink start by listening for a Wi-Fi Direct layer 2 beacon on the 2.4-GHz–band social channels. One of them—typically, the source—scans for a list of the other—in this case, the sink. The source collects the responses and presents them to the user or chooses one on the user’s behalf. Next, the source initiates a connection to the selected sink. A negotiation results in one of them becoming the group owner, which is similar to an access point (AP). With a connection established, a negotiation primarily consisting of video frame rate, frame size, and encryption as well as audio format occurs. Recall that the compression is always H.264 in an MPEG2 wrapper. Both embedded MPEG streams and out-of-band (OOB) control signals inform the sink of the variable data rate and potential midstream format changes.
Miracast is flexible in that you can think of it as an HDMI cable replacement. The sink device requires only a Wi-Fi Direct–aware Wi-Fi driver and a media pipeline that can play a streaming H.264 video. A 2x2 dual-band radio in both the source and the sink is not a Miracast requirement, but a good implementation would always use one. Some more advanced implementations can require that the Wi-Fi radio simultaneously keep a connection to an AP and also “listen” on the social channels, and then support a Wi-Fi Direct connection. An example is a smart TV acting as a sink that is always waiting for a Miracast connection while maintaining the connection to the AP. This method does not require the user to put the TV in Miracast Listen mode.
The second screen can either be Miracast capable or use a small adapter (available from multiple manufacturers typically as an HDMI dongle and often powered via USB). Miracast is also available in consumer add-on devices, including Blu-ray* players, and set-top boxes that stream cable TV channels to smartphones. The user device can be Windows* 7 or later or Android*, Kindle* Fire, or Samsung Wi-Fi AllShare Cast* capable.
The important technology differences with Miracast are:
- No AP is required.
- Internet connectivity is not required (unless the user wants Internet content on the host device).
- Native support is available in Windows 8.1, Android 4.2 and later, and Kindle Fire.
The host device encodes and streams an MP4 video. Note: When using Presentation Surface from Windows 8.1 or Android 4.4, you must set up the second screen connection from the Project menu or the KitKat menu.
About the only downside to Miracast comes from streaming video content from the cloud to the TV. In this scenario, a second Wi-Fi hop must be made from the AP to the source to the sink, which requires that the source always be powered on to perform the video transcoding and could drain a battery should the source not be connected to wall power. You might also see video artifacts in the final display caused by the decompression, and then recompression of the video before it is transmitted to the TV.
Intel® Wireless Display ![]()
Intel WiDi has been commercially available since 2010, adding Miracast support in 2012 (version 3.5). All of the above Miracast features are available with Intel WiDi. Approximately 40 million laptops have shipped with Intel WiDi preinstalled on them. Intel WiDi supports Windows 7 and Windows 8/8.1.
Intel Pro WiDi is new to business-class systems and designed for conference room scenarios, where multiple computers need to connect to a single, large display. Intel Pro WiDi includes a fast handoff and secure connection capability and supports the management of settings on projectors or Intel Pro WiDi–certified displays using the Simple Network Management Protocol, a command-line interface, or a Web user interface.
Intel WiDi provides the base platform capability of a wireless display. The biggest advantage for ISV developers that want to create novel dual-screen applications is that nothing additional is required. Developers can use a wide range of programming languages to develop dual-screen apps. There are a number of standard OS API calls, including detection of a second display connection, creating a new window full screen and borderless window on the second display.
Google Cast* (API) and the Chromecast* Dongle
Google produces an inexpensive hardware dongle (Chromecast) that can plug into any display that has an HDMI port. This dongle downloads content from the Internet by connecting wirelessly (802.11) to a wireless AP on the LAN. Under the hood, Google Cast is quite different from the other solutions and is really a combination of two technologies. The primary mode is playing cloud content using URL redirect. Briefly, URL redirect defines how an application can send a URL to the Chromecast dongle to be rendered on the TV.
The Chromecast dongle, when connected to the TV, must first be configured to gain LAN and Internet access via the local AP using standard Wi-Fi (802.11). The dongle then listens for a layer 5 Discover and Launch service discovery based on Simple Service Discover Protocol version 1.1, part of the Universal Plug and Play standard.
The application collects the responses and presents them to the user or chooses one on the user’s behalf. When the app invokes the connection via the Google Cast API, it creates a socket to the selected Chromecast dongle over a TCP/IP connection. Over this TCP connection the Google Cast API enables any application on the platform to start using the Chromecast dongle to “cast.” These APIs cause various actions to occur on the Chromecast dongle. It can pass a URL to render directly from the Internet as well as play and control Internet video content. It can even be used to pull down an application to run on the Chromecast dongle for a customized experience.
For example, a content provider can create a website that offers a catalog of video content. Using the Google Cast API plug-in, a URL obtained from the content provider’s website is then sent to the Chromecast dongle to be played. In addition, Google provides an API to remotely control (play, pause, fast forward, rewind) the video stream player on the Chromecast dongle from the sending device. The secondary mode is based on steaming local content and screen mirroring. Google has recently enabled a duplicate mode based on its own API, which is unique and specific to Chromecast.
Google Cast is flexible in that you can start playing a video on the Chromecast dongle and it does not require the “casting” device to take any action; it can even power down. In addition, the ability to have just-in-time, downloadable, dongle-side apps makes this solution flexible.
The downside to Google Cast comes when playing local video content, because it requires a second Wi-Fi hop from the source to the AP to the Chromecast dongle. In addition, the current Chromecast dongle has a 1x1 Wi-Fi radio that typically does not perform well in crowded Wi-Fi environments.
Apple AirPlay* to Apple TV*
Apple TV* and AirPlay share several traits with Google Cast: both require proprietary devices and specific software downloaded from their online stores. Although major content providers (YouTube*) have included both technologies, other major providers (Amazon videos) may not run on them.
Only Apple hardware or devices running iTunes* work with Apple TV. In audio, other manufacturers, including Denon, JBL, Marantz, Pioneer, and Sony, have licensed AirPlay to allow audio-only streaming through their device from an Apple device. Developers must use Apple APIs to call AirPlay, and their app must go through the Apple Store approval and distribution process, although the Apple developer site has a wide range of documentation and Objective-C* (and soon, Swift) sample code available. Usability is as good as expected, but proprietary.
Compare and Contrast
It’s important to consider the differences and similarities among these technologies from different perspectives. If you consider a business use case scenario where multiple laptops need to connect to a single large-screen device for a presentation, you need the ability to quickly connect and disconnect individual devices. It’s also possible that Wi-Fi might not be available, making the Miracast/Intel WiDi solution the only viable option outside of using cables.
From a developer’s perspective, you must evaluate the target audience and the potential market for any application under consideration. Although the Apple ecosystem is obviously a strong leader in the consumer market, there are huge numbers of PCs that run Windows with Miracast preinstalled and Android phones and tablets with Miracast preinstalled (Android 4.2 and later).
The actual development process is quite different depending on the target solution. For a Miracast/Intel WiDi target, you do not need any additional code to display content on a second screen: everything works just like a normal application. If you’re targeting Google Cast, you need to learn a new set of API calls and to write code that runs inside the Chrome* browser. For an Apple target solution, you must go through the Apple Store and integrate with AirPlay.
Screen sharing is one use case that all three solutions support at some level. The differences show up in how the connections are made and controlled.
Architectural Differences
Miracast uses Wi-Fi Direct technology, which provides direct, point-to-point or peer-to-peer connectivity (no AP needed). Both AirPlay and Google Cast use a wireless AP to make the connection (two hop) from the local device
Note: Google Cast now allows a handoff to the dongle using an OOB HTTP session to start and stop the stream, with conversion prior to transmission on the 1.2-GHz system on a chip dongle and 16 GB of flash of memory and 512 MB of RAM.
Most Intel WiDi devices use a 2x2 dual-band radio so that the PC can stay connected with both the second screen and an AP for Internet connectivity.
In addition, Miracast adds specific protocol to negotiate video capabilities, configure encryption if necessary, stream content, and maintain the video session.
Note: Compression is always H.264 in an MPEG2 wrapper. Packets contain both the embedded MPEG stream and OOB control signals to inform the second screen of the variable data rate and any midstream format changes.
Intel Pro WiDi adds privacy, security, and manageability features not available elsewhere.
Compatibility
AirPlay works best with other Apple devices and requires Apple TV as well as iTunes on non-Apple devices. Google Cast works on any operating system that can run the Chrome browser and requires the Chromecast dongle. Windows business devices need a Chrome browser plug-in. Miracast works out of the box on Windows PCs and Android 4.2 and later devices. There are many Miracast dongles available from multiple vendors.
For More Information
- Learn more about Intel WiDi: http://www.intel.com/go/widi.
- Download Microsoft projection app code from http://code.msdn.microsoft.com/windowsapps/Projection-sample-526b3c1d.
- Miracast on Windows 8.1 Desktop has a code sample for texture sharing from the Intel Media SDK to OpenGL*.
- Check out Why WiDi Miracast is a Game Changer for Android.
- Read How to Enable Intel Wireless Display Differentiation for Miracast on Intel Architecture Phone.
- Find adapters for Intel WiDi.
About the Authors
Paul Ferrill has been writing in the computer trade press for more than 20 years. He got his start writing networking reviews for PC Magazine on products like LANtastic and early versions of Novell Netware. Paul holds both BSEE and MSEE degrees and has written software for more computer platforms and architectures than he can remember.
Steve Barile has over 25 years’ experience in the tech industry working on video codecs and various media infrastructures. He is currently a Technical Evangelist for Dual Screen application enabling and has been in Intel’s Wireless Display group since early 2010.