Windows Media Technologies Application Development (Windows Embedded CE 6.0)

Article
01/05/2012

1/6/2010

Developers can use Microsoft® Windows Media® technologies for Windows Embedded CE to provide multimedia streaming capabilities to Windows Embedded CE devices. These capabilities include support for the streaming formats and protocols required for audio and playback of local files or streamed data over a network connection.

What follows is a look at the formats, functionality, and protocols supported by Windows Media technologies for Windows Embedded CE.

Windows Media Formats

To store and stream data, Windows Media technologies for Windows Embedded CE support:

Advanced Streaming Format (.asf)
Advanced Stream Redirector (.asx) metafiles
Microsoft Windows Media Station (.nsc) metafiles

Advanced Streaming Format

Advanced Streaming Format is an application-level multimedia transmission file format (as opposed to a wire or transmission control format) that arranges and organizes synchronized multimedia data. ASF supports media data delivery over a wide variety of network types, network bandwidths, and protocols. It is optimized for streaming multimedia packets over both low bit-rate and broadband networks for content such as Windows Media audio and video.

Advanced Stream Redirector

The Advanced Stream Redirector metafile provides mechanisms by which a client can support hyperlinks to streams, support specification of multiple pieces of source content, and the protocol rollover rules the client will use to process them, as well as support media play lists.

Windows Media Station

The Microsoft Windows Media Station metafile serves to describe a particular channel to an ASF client wishing to access that channel. The model for access to a channel is similar to a television accessing a broadcast channel. This metafile is used for multicasting support.

Windows Media Functionality

Windows Embedded CE provides Windows Media technologies client DirectShow filters that allow playback of ASF streams sent using User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Hypertext Transfer Protocol (as described below).

Smart Streaming

Windows Media technologies for Windows Embedded CE support smart streaming using a multi-data rate encoded ASF file, where multiple streams with different bit rates are created in one ASF file and the client negotiates with the server for the appropriate stream. The server then automatically adjusts the stream depending on playback conditions and can select from multiple video streams based on available network bandwidth.

With smart streaming, the Windows Embedded CE Windows Media technologies client can dynamically thin the stream based on the available bandwidth using an algorithm that adjusts delivery smoothly from full frames down to key-frame only. If necessary, the Windows Media technologies client can ask the server to send only audio and no video packets. As bandwidth is reduced, audio is always given the highest priority because it is usually critical to the user experience. As network bandwidth conditions improve, Windows Media technologies can progressively step the video bit-rate back up to restore the viewing to an optimal level. In addition, by using the Windows Media technologies UDP resend capabilitythe client can, if time is available, request missing packets from the server.

Windows Media technologies also provide ASX event-driven stream switching where the client sends ASX control commands to the server.

Authentication

Windows Media technologies for Windows Embedded CE provide support for authentication. Authentication involves user validation before any information is exchanged between client and server.

When a client initiates a request to the server that has authentication enabled, the server challenges the client to confirm its identity. Typically, this challenge involves inspecting the name and password of the user account under various authentication protocols.

For any given interaction, both client and server must adhere to one agreed authentication protocol. Windows Media technologies support two authentication protocols:

HTTP-Basic for Internet applications
NTLM, which is suitable for intranet applications

On the desktop, NTLM uses authentication information established when the user logs on and requires the client and server to be on the same or privileged domains. Because Windows Embedded CE does not allow a user to log in, Windows Media technologies opens a dialog box asking for authentication information when NTLM authentication is required.

Windows Media Protocols

Windows Media technologies support the following protocols: multicasting, local file streaming, Microsoft Media Server (MMS) streaming, and HTTP streaming.

Multicasting

Multicasting enables the client to receive multicast streams. Therefore, an administrator can send one copy of content to many users on the network if that network is multicast-enabled. Internet Protocol (IP) multicast streaming is done through ASF with the Windows Media Station metafile.

Networks that are not multicast-enabled and ASF files that are not streamed from a Windows Media server are sent through unicast. Unicast involves one stream each request.

Local File Streaming

Windows Media technologies can provide local file streaming for systems with persistent storage. Data is read from persistent storage into a buffer in main memory and then rendered. Local file streaming provides lower latency and a significant physical memory savings over reading the entire ASF file from the persistent store into main physical memory before rendering the file.

MMS Streaming

MMS is the Microsoft proprietary protocol for streaming media. A typical MMS session uses a TCP connection for sending and receiving media control commands, and a UDP or TCP connection for streaming the data.

Invoking the MMS protocol using the mms:// URL invokes the protocol rollover mechanism. The client first tries to receive the stream through UDP. If UDP does not work, the stream automatically rolls over to TCP transmission. Finally, if TCP does not work, the client will try to receive the stream through HTTP.

The MMSU protocol enables the client to receive MMS streams through UDP. It is well suited to audio because it sends packets regardless of connection quality. Therefore, users hear fewer delays and pauses. If time allows, missed packets are requested and resent.

The MMST protocol enables the client to receive MMS streams through TCP. TCP forms a reliable stream — if packets are lost, the stream stops and lost packets are recovered. Users experience more delays and pauses over a network that is congested.

HTTP Streaming

An HTTP server can deliver ASF data streams, but using Windows Media Server offers advantages:

Avoiding fragmentation: The packets within an ASF data stream must be delivered sequentially, one per network packet, for the full benefit of data streaming to be realized. An ASF-compatible server such as Windows Media Server avoids fragmentation by transmitting ASF packets one at a time These packets are encapsulated neatly within individual Internet or other network protocol packets.
On-the-fly determination of where ASF packets begin and end: The error correction, streaming playback, and bit-rate optimization inherent to ASF depend on the client and server not having to figure out where ASF data packets begin and end on the fly. An HTTP server does not have this ability because it does not recognize the significance of ASF packets; it just shoves data to the client as quickly as possible by filling each network packet with an arbitrary amount of data.

Additionally, several capabilities of Windows Media, such as the ability to fast-forward or rewind ASF data streams, are not available on an HTTP server.

For more information, ASX Elements Reference Windows Media Event Notification Codes and Comparing HTTP Streaming Protocol with RTSP