Windows Media Overview and Optimization for Windows CE .NET 4.2

Windows CE .NET

Brian King
Microsoft Corporation

November 2003

Applies to:
    Microsoft® Windows® CE .NET 4.2
    Microsoft® Windows Media®
    Microsoft® Windows® XP
    Microsoft® Windows Mobile™-based Pocket PC
    Microsoft® Windows Mobile™-based Smartphone


This document provides an overview of the Windows Media-related components delivered in Windows CE .NET 4.2, compares and contrasts them to those components available on Windows XP, Windows XP Embedded, Pocket PC, and Smartphone, and offers tips and techniques for optimizing the performance of Windows Media on a Windows CE .NET 4.2-based platform.


Windows Media Codecs
Windows Media File Format (ASF)
Windows Media Digital Rights Management
Windows Media Player ActiveX Control (OCX)
Windows Media Player Application
Windows Media Software Development (WM-SDK)
Optimizing Windows Media Performance in Windows CE .NET 4.2
Example IPTV Client/Server Settings for Windows Media 9 Series Streaming
Related Links


Microsoft Windows Media is a broad collection of technologies and software offerings within Microsoft Windows CE .NET 4.2, Microsoft Windows Mobile 2003-based Pocket PC and Smartphone, and Windows XP. It often presents a bewildering array of terminology and capabilities that differ between these Windows operating systems. It is important for anyone implementing Windows Media solutions in Windows CE .NET to understand these differences and capabilities, and to tune their product offering for optimal performance.

This article covers the major Windows Media components in the following order:

  • Windows Media Codecs (WMA, WMV)
  • Windows Media File Format (ASF)
  • Windows Media Digital Rights Management (DRM)
  • Windows Media Player ActiveX® Control (WMP OCX)
  • Windows Media Player Application (WMP)
  • Windows Media Software Development (WM-SDK)
  • Platform Optimization and Diagnostics

Windows Media Codecs

Windows Media compression technologies are the key to delivering a great audio/video playback scenario to your customers. The latest versions of these technologies are the Windows Media 9 Series codecs. Windows Media Audio (WMA) files offer equivalent or higher quality to MP3, but at a lower bit-rate and file-size, allowing for increased storage or bandwidth availability. Windows Media Video (WMV) files offer higher quality than MPEG-4 Simple Profile or MPEG-2, again at a lower bit rate and file size. More information and comparisons about the Windows Media 9 Series Codecs can be found on the Windows Media 9 Series Audio and Video Codecs page.

There are different capabilities of WMA and WMV content consumption across the operating system choices, as shown in the following table:

Operating System Windows XP Windows Mobile 2003 (Pocket PC, Smartphone) Windows CE .NET 4.2
WMA 9 Standard
WMA 9 Lossless    
WMA 9 Professional    
WMA 9 Voice
WMV 9 Image
WMV 9 Screen    

Further details about the Windows Media 9 Series Codecs can be found at the 9 Series Codecs - Audio page and the 9 Series Codecs - Video page.

Windows Media File Format (ASF)

The Advanced Systems Format file container stores the following in one file: audio, multi-bit-rate video, metadata (such as the file's title and author), and index and script commands (such as URLs and closed captioning).

To ensure that content is associated with compatible players, there are several different file extensions. The file extension used should be:

  • .WMA for files that contain only audio compressed with the Windows Media Audio codec, or
  • .WMV for files that include both audio and video compressed with Windows Media Audio and Windows Media Video codecs.
  • .ASF for files compressed with other codecs.

Figure 1. Advanced Systems Format file container

More information can be found on the Windows Media Format page.

There are different levels of Windows Media Format support across the operating system choices, as shown in the following table:

Operating System Windows XP Windows Mobile 2003 (Pocket PC, Smartphone) Windows CE .NET 4.2
Audio / Video Codecs
Digital Rights Management*

*See the following section for details on the DRM capabilities of each operating system.

Windows Media Digital Rights Management

Windows Media Digital Rights Management (DRM) is an end-to-end system that offers content providers a flexible platform for the secure distribution of digital media files and consumers the ease of use needed to accompany and enjoy digital media experiences. The first version of Windows Media DRM was released in August 1999. In 2002, Microsoft released Windows Media DRM version 7, offering greater flexibility and better security to its users. The latest release, Windows Media DRM 9 Series, launched in January 2003, supports real-time encryption (also known as "Live DRM") and enables content to be delivered simultaneously to consumers as it happens.

There are different levels of Windows Media DRM support across the operating system choices, as shown in the following table:

Operating System Windows XP Windows Mobile 2003 (Pocket PC, Smartphone) Windows CE .NET 4.2
DRM v1    
DRM v7+, v9  
Portable Device DRM  
SDK available for ISVs    

DRM v1 allows the following business rules for protected content:

  • Expiration Date
  • Unlimited Play
  • Transfer to Secure Digital Music Initiative (SDMI) or non-SDMI
  • Burn to CD

DRM v7+ adds the following business rules and functionality:

  • Start time
  • End time
  • Duration
  • Counted operations (plays, transfers)
  • Silent license acquisition
  • Predelivery of licenses
  • Backup and restore of licenses (not supported in Windows CE .NET 4.2)

DRM v9 enables protection and licensing of live video encoding ("Live DRM"), and applies at the content encryption stage (not at the client level). All v7+ and v9 clients are able to receive and view a protected live stream.

There are three different scenarios for a Windows CE .NET 4.2 device to acquire licenses (rights) to playback DRM protected Windows Media files:

  • Portable Device DRM (PD-DRM): The protected content is on a desktop computer to which the Windows CE .NET device is directly connected (using Microsoft ActiveSync®). Using the Windows Media Player on the desktop computer, an end-user is able to transfer this protected content to their "portable device," provided that the Digital Rights for the content allow such transfers.
  • Silent License Acquisition: The protected content is on a server to which the Windows CE .NET 4.2 device is connected (using Transmission Control Protocol/Internet Protocol [TCP/IP]). The device can download a license for the protected content, without prompting for any form of user input.
  • Nonsilent License Acquisition: The protected content is on a server desktop computer to which the Windows CE .NET 4.2 device is connected (using TCP/IP). The device can download a license for the protected content, by navigating the user to a Web page which requires user input. This navigation requires Microsoft Internet Explorer and the DRM License Acquisition OCX to be included in the device's feature set.

Although Windows CE .NET 4.2 fully supports playback of DRM v7+ and v9 content, it does not expose certain DRM functionality through a software development kit (SDK). An original equipment manufacturer (OEM) or independent software vendor (ISV) is unable to back up or restore their licenses; query content for its license-state (Is the content expired? How many more times can the content be played? Will the content expire soon?), or accomplish some of the other operations available on Windows XP through the Windows Media Format SDK (WMF-SDK).

Although DRM appears in the Windows CE .NET Platform Builder feature catalog, the software components that enable DRM do not ship with Platform Builder. An OEM wanting to include DRM in its Windows CE .NET 4.2 platform must register with Microsoft to obtain the necessary DRM components. Microsoft will then provide unique, digitally signed components to the OEM. Although these components are unique to each OEM, they can play back any content protected by DRM v7+, and v9. To request licensing instructions for DRM v7+ and v9 in Windows CE .NET 4.2, contact your distributor or account manager.

Windows Media Player ActiveX Control (OCX)

You can build Windows Media playback functionality into a Web page by embedding the Windows Media Player ActiveX Control (OCX). One aspect of embedding the WMP OCX is that you have complete control over the look of the player and how it functions—in other words, the entire user experience. You can create a player that works with the design of a page and its contents and you can expose only those functions that are appropriate. You can, for example, expose only two buttons—play and stop—and set the player to play only one file.

Another aspect of embedding the WMP OCX is that along with being able to control the player with Web page script, you can add script that enables you to control the Web page with the player. For example, you can add script commands to a Windows Media file or live stream that changes images in a frame or sends dynamic Hypertext Markup Language (HTML) commands to Microsoft Internet Explorer in synchronization with the media.

There are different levels of WMP OCX support across the operating system choices, as shown in the following table:

Operating System Windows XP Windows Mobile 2003 (Pocket PC, Smartphone) Windows CE .NET 4.2
WMP v6.4
WMP v7.x, v9    

*See the Platform Builder documentation for information on the WMP OCX available for Windows CE .NET 4.2.

For Windows CE .NET 4.2, see the Adding Windows Media to Web Pages article.

The WMP v6.4 OCX has the broadest set of compatibility for web-content authors, and includes support for other Microsoft operating systems besides those listed previously, including Windows 95, Windows 98, Windows Millennium Edition, Microsoft Windows NT®, and Windows 2000. The newer v7+ OCX has an entirely new object-model and set of scripting commands when embedding the control. An example of how to embed the different versions of the WMP OCX is available online from MSDN®. (See the Adding Windows Media to Web Pages article).

Important   As an OEM creating a Windows CE .NET 4.2-based product, you will want to verify that any key Web sites which employ the WMP OCX are either using the WMP v6.4 OCX for broadest compatibility, or have the appropriate scripting embedded in their Web page for determining the type of client which is connecting, and then offering up two possible Web page styles (one featuring the v6.4 OCX, the other with the v7+ OCX). For example, when creating a Windows CE .NET 4.2 set-top box (STB) for video-on-demand (VoD) scenarios, the OEM should work closely with content providers to ensure that the VoD Web pages will work correctly on the device.

Windows Media Player Application

The Windows Media Player application in Windows CE .NET consists of sample-code which OEMs are free to modify at the source-code level in order to obtain their own unique functionality, behavior, and branding. This sample source-code is included in a Platform Builder installation, under the public\directx\sdk\samples\wmp\ceplayer\ directory location.

Because this player application is a sample, it is not as full-featured as the Pocket PC or Smartphone offering, or the Windows Media Player XP or Windows Media 9 Series Player. An additional source of confusion for Windows CE .NET customers is that the Windows Media Player (CEPlayer.exe) in Windows CE .NET is a wrapper around the WMP v6.4 OCX, is documented as supporting DRM v7+, and yet can play back Windows Media 9 Series content (WMA/WMV v9).

Important   The Windows Media Player in Windows CE .NET is a sample application, and not a direct implementation of Windows Media Player XP or Windows Media Player 9.

The different levels of Windows Media Player application support across the operating system choices are shown in the following table:

Operating System Windows XP Windows Mobile 2003 (Pocket PC, Smartphone) Windows CE .NET 4.2
WMP XP, WMP 9 Series (Corona)    
WMP v6.4    
WMP Sample (CEPlayer)    
WMP 9 Series

(Pocket PC, Smartphone)


Because each player has a unique name, version, and feature-set, it is better to compare the actual features supported by the media player application. The following table lists the key features and differences between the three different Windows Media Player offerings:

Feature WMP XP, WMP 9 Series (Corona) WMP Sample (CEPlayer) WMP 9 Series (Pocket PC, Smartphone)
WM 9 Series Content Playback
MP3 Playback
MPEG1 Playback  
AVI Playback  
Pluggable File Formats and Codecs*  
Fast Start Support
Fast Cache Support    
HTTP Download (Caching)    
HTTP Streaming Support  
MMS Streaming Support
RTSP Streaming Support    
DRM v7+, v9 Support  
PD-DRM Support  
Media Guide  
CD Ripping    
CD Burning    
Media Library
Playlist Creation
Transfer to Portable Device    
Internet Radio Tuning    
DVD Playback  
Source Code for OEM Customization    
DSP Effects    
License Management    
Player Controls in Taskbar    

*Plug-ins could include support for DivX, MPEG2, MPEG4, MotionJPEG, QuickTime, and other formats. OEMs are free to write these plug-ins, or license them from ISVs.

+CEPlayer.exe features a button to launch the Web page, as opposed to hosting the page directly inside the Windows Media Player via a "Media Guide" view.

#DVD playback is provided through a separate sample application.

Windows Media Software Development (WM-SDK)

There are a broad set of application programming interfaces (APIs) for Windows Media in each operating system. In some cases, a full set of C, C++, and Microsoft Visual Basic® APIs exist (such as with the Windows Media Format SDK and DirectShow® SDK), while in other cases a more limited OCX programming model is available. The following table illustrates the SDK offerings across each operating system choice:

Operating System Windows XP Windows Mobile 2003 (Pocket PC, Smartphone) Windows CE .NET 4.2
Windows Media Format SDK    
DirectShow SDK  
WMP v6.4 OCX
WMP v7+, v9 OCX    

Optimizing Windows Media Performance in Windows CE .NET 4.2

In order to attain the best possible Windows Media playback performance in Windows CE .NET 4.2, there are some key features which should be present whenever possible. This section assumes familiarity with Windows CE .NET, its OEM abstraction layer (OAL), and its networking, display, and audio driver models.

Ensure All QFEs Installed

Important   Be sure that your Windows CE .NET installation has all applicable quick fix engineering (QFE) updates installed, as there are a number of QFEs applicable to Windows CE .NET 4.2 which address WM performance issues. Read the documentation included with each QFE, as some require associated OAL or registry changes to yield best results.

Performance Profiling

By using the Monte Carlo profiling support in Windows CE .NET, you can measure the amount of CPU-time spent in various modules (components) of the system, in addition to the amount of CPU-time spent in idle. In order to measure CPU-time of any modules, those modules must be included in the MODULES section of nk.bin, and must have symbol information (.pdb files) available in the _FLATRELEASEDIR of the platform being profiled.

Monte Carlo profiling is a sample-based approach used to track Program Counter (PC) location during execution. Further information about this profiling support is available in the Platform Builder documentation. An especially useful thing is to use the F9 (start) and F12 (stop) keys on your target platform's keyboard, in order to start/stop profiling.

Profiling can be enabled via Platform Builder's Platform Settings dialog box, with the Enable Profiling option:

Figure 2. Platform Settings dialog box with Enable Profiling option

Network Drivers

Choose a network adapter and driver which support DMA-based transfers for less CPU utilization during higher-bandwidth streaming scenarios. In addition, ensure that the network adapter is not sharing any interrupts with other hardware in the system, if possible.

The most common source of performance issues when first configuring a Windows CE .NET 4.2 device is that the customer is using a debug-build, or that the customer has included VMINI support into the platform. VMINI support enables "product" Ethernet over the debug Ethernet connection. VMINI lets a device support Platform Builder for debugging and also have full network connectivity. This mechanism is not suitable for streaming media. To avoid this configuration issue, add a secondary network card for "product" Ethernet, and do one of the following:

  • Disable the VMINI network adapter at run time through the Network Control Panel
  • Disable VMINI support entirely in the platform (BSP_NOSHAREETH=1), accessed through Platform Builder's Platform Settings dialog box:

Figure 3. Environment tab of Platform Settings dialog box

Display Hardware Features (Video Playback)

Having display hardware that supports YUV formats, or has YUV-to-RGB color-space conversion hardware, can offload anywhere from 10-20% of the WMV decoding process. This is because WMV content is stored internally in a YUV format, and the codec must convert a YUV frame of data into an RGB frame on display-devices that do not support YUV formats. The conversion happens per frame, n times per second (typically fifteen to thirty frames-per-second), and it is also impacted by the resolution of each frame (typically 320x240 or 640x480).

The optimal YUV surface-types to support are listed below in priority order:

  • YV12
  • YUY2
  • UYVY
  • YVYU

In addition, YUV format support is often tied to the concept of an overlay surface in display-hardware. Overlay surfaces can provide hardware-based color-conversion from YUV-to-RGB, in addition to scaling support, and page-flipping, all independent of CPU intervention.

In order to expose support for these features in Windows CE .NET 4.2, you must support both GDI and DirectDraw in your display driver. If your driver is Graphics Primitive Engine (GPE)-based, then the simplest way to add DirectDraw® support is to migrate your driver to the DDGPE model. Full source-code is included with Platform Builder for many sample DD GPE-based display drivers.

Audio Hardware Features (Audio/Video Playback)

Including DirectSound® in the Windows CE .NET image may result in an extra emulation-layer being used, depending on whether the underlying audio-driver supports DirectSound or is only a WaveDev-style driver. Unless your platform requires DirectSound APIs or features, it is advised to avoid including DirectSound. This can also reduce the effort required to write a Unified Audio Model (UAM) driver which supports both DirectSound and WaveDev.

General System Optimizations

If the Windows CE .NET image is being executed from flash-memory on the device, you may wish to mark the following components as compressed in the directx.bib file, under the Modules section:

  • WMVDMOD.DLL (Windows Media Video Decoder DMO)
  • WMADMOD.DLL (Windows Media Audio Decoder DMO)
  • WMSDMOD.DLL (Windows Media Audio Speech/Voice Decoder DMO)
  • QUARTZ.DLL (DirectShow)
  • DXMASF.DLL (Windows Media Source Filter)

By marking these modules as compressed, they will not be executed out of flash-memory, and instead will be expanded into random access memory (RAM) for execution. Because RAM access-speed is usually much higher than flash-memory access-speed, executing from RAM is typically faster. Here is an example from directx.bib for some of these modules:

    wmvdmod.dll    $(_FLATRELEASEDIR)\wmvdmod.dll              NK  SHC
    wmadmod.dll    $(_FLATRELEASEDIR)\wmadmod.dll              NK  SHC
    wmsdmod.dll    $(_FLATRELEASEDIR)\wmsdmod.dll              NK  SHC

Alternatively, if the image is being executed from main-memory, there is no need to mark these modules as compressed, and the 'C' flag should be removed from directx.bib.

Registry Settings

There are numerous registry-settings that impact both the performance and the ability to diagnose Windows Media playback.

WM Source Filter

The WM Source Filter is responsible for reading an ASF stream from disk or a remote server, parsing it, splitting it into an elementary audio and video stream, decrypting it (if protected using DRM), and finally dispatching the data off to the Windows Media 9 Series codecs.

This component will automatically try to determine available network bandwidth for streaming scenarios. If you have a fixed maximum bandwidth available on your platform, and this automatic detection is not working correctly, you can set the bandwidth with the following registry-key in platform.reg:

"ManualBandwidth"=dword:16E360 ; 1.5 Mbps as an example

Individual streaming formats can be disabled as well. This is occasionally useful if behind a firewall which does not allow for MMS streaming, or if MMS UDP streaming is providing worse playback performance than MMS TCP or HTTP streaming.

; Set these to 0 to disable specific protocols for WMT

Windows CE .NET 4.2 includes "Fast Start" support when streaming from a Microsoft Windows Server™ 2003 configuration. There are a number of registry keys that can affect Fast Start performance and behavior, depending on a particular system.

"Buffering Time"=dword:bb8      ; default 3000. Can be controlled by Media Player
"FSEnable"=dword:1              ; fast start enable. default on
"FSTime"=dword:1770             ; fast start time. default 2*"Buffering Time"  
"FSLinkBandwidth"=dword:989680  ; link bandwidth. default calculated by packet 
pairs or history. if unavailable 10mbs
"FSAccBandwidth"=dword:2DC6C0   ; acc. bandwidth. default 10mbs  
"MSB Buffering Time"=dword:380  ; override buffering time for MSB protocol to allow 
optimized (shorter) preroll for multicast

Finally, if your device is experiencing large amounts of packet-loss when streaming over UDP, try configuring the system such that the network driver and audio driver are not sharing interrupts. Alternately, try changing the minimum receive-buffer on the network sockets that the WM Source Filter is creating:

"MinRcvBuf"=dword:40000 ; set to 256K (default is 32K)

WMV Decoder DMO

The WMV decoder in Windows CE .NET has the ability on x86 CPU architectures to perform post-processing (such as de-blocking) based on an internal algorithm that tries to automatically detect system capabilities. Sometimes, this automatic detection is incorrect, and post-processing is incorrectly enabled on a system. This post-processing stage is very resource-intensive, and can have the adverse effect of degrading your playback performance. To disable it, use the following registry-key in your platform.reg file:

Additionally, the WMV Decoder has built-in frame-dropping heuristics that may 
become overly aggressive about when to not decode a given video frame. 
This can cause dropped frames of video or it can cause playback to skip 
a number of sequential frames until the next key-frame appears. 
This type of frame-dropping can be disabled with the following 
registry-key in your platform.reg file:

To diagnose performance issues for WMV decoding, enabling frame-time debug-output is very useful. This mode will output the time (in milliseconds) to decode a given WMV frame, in addition to the time it takes for the frame to be written to the output buffer. To enable it, use the following registry-key in your platform.reg file:


Set n to 10 or larger, otherwise the overhead of the debug output will greatly affect the timing. Using this in combination with DoNotDropFrames=1 is advised when engaging in diagnostics.

For thirty frames-per-second (30fps) content, each frame has 33.33 milliseconds available in time. If the decode time is taking 20 milliseconds, and the output time is taking 5 milliseconds, then playback should be within the performance envelope (not accounting for streaming issues, DRM decryption, and general system overhead).

If the output time is quite high, ensure that your memory bus is configured optimally on your hardware platform (DRAM timing settings, basic input/output system [BIOS] settings, and so on), that any applicable memory buffers are being marked as write-combined (also known as bufferable) in the display-driver, and that you are not writing across an inefficient hardware bus (16-bit wide, for example).

DirectShow Video Renderer

Depending on the underlying display driver implementation and hardware, using flipping (back-buffers) can cause performance issues. Experimentation with the following registry-key can be useful:

[HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX\DirectShow\Video Renderer]

The default for this value is 1, with a range from 0 to 2. If you see problems such as stalls in the decoding pipeline or many dropped frames, then try setting this to 0 or 2. If this helps, then it is likely there is a problem with the flipping logic in the display driver.

Network Redirector (Accessing a File-Share)

When playing content from a remote file-share through the Network Redirector in Windows CE .NET (in other words, accessing \\machine-name\share-name\media-file.wmv), you may need to adjust the amount of buffer available on the Windows CE .NET client:


The default value is 0x1000 (4096 bytes) – try increasing this value in increments of 4K.

Example IPTV Client/Server Settings for Windows Media 9 Series Streaming

These are example settings that can be used to improve the start-up time and channel change latency characteristics of a Windows CE .NET client in an IPTV configuration. Because each network configuration and characteristics are unique, different settings may work better for your scenario.

Example IPTV Network Using WM 9

Link bandwidth 2 Mbps for multicast; 6 Mbps for unicast
Content bit rate 1 - 1.5 Mbps depending on the Telco specification
FEC 10:1 or disabled, as noted
Key frame distance 1 sec
Encoder buffer 1 sec
Client buffer 1 sec
Encoder quality 0%
Resolution 1/2D1: 360x480  (PAL = 352x576)
Frame Rate 29.97 fps (PAL = 24fps)
Scan type Interlaced, with "Maintain Interlacing / Set to bottom" in encoder
Packet size 1400 bytes
Client Windows CE .NET 4.2 + QFEs
Server Windows Media Services 9.0
Topology WMS9S --> Cisco 4700M+ Router --> Packet PacketShaper 4500 --> Client
Sample size Average latency results based on 30 samples

On the server

  • Use default publishing point settings.
  • Ensure "Enable Buffering" is On under Networking on the publishing point.
  • Ensure Fast Start is enabled.
  • Disable data bursting:
    1. Stop the server running Windows Media.
    2. Go to %WINDIR%\system32\windows media\server.
    3. Open servernamespace.xml file in the notepad.
    4. Find the string "OutstandingBytesQuota". You will see an Extensible Markup Language (XML) element looking like this: 
      <node name="OutstandingBytesQuota" opcode="create" type="int32" value="0x10000" />
    5. Add the following two lines immediately after that line:
      <node name="UDPBurstLimitMs" opcode="create" type="int32" value="0x0" />
      <node name="TCPBurstLimitMs" opcode="create" type="int32" value="0x0" />
    6. Save the XML and restart the service.

On the encoder (whether live or when encoding content):

  • Set key frame distance to 1 second.
  • Set buffer to 1 second.

On the Windows CE .NET client

  • Change the following registry keys as necessary to improve performance for this type of scenario:
    "Buffering Time"=dword:3E8
    "MSB Buffering Time"=dword:1F4


The built-in Windows Media support in Windows CE .NET 4.2 provides an incredible advantage to OEMs building embedded systems and consumer-electronics devices. Without having to license external codecs or streaming-solutions, the customer is able to quickly enable high-quality streaming audio and video playback for a variety of product categories. By following the best practices laid out in this white paper, the OEM can make strides toward ensuring optimal playback quality in their Windows CE .NET 4.2 solution.

Related Links

See the following resources for further information: