Media Center Extender Technologies

I came across the information below the other night while I was doing a search for something Media Center related. It may not be big news, but maybe it will help someone.

Below is an excerpt from this MSDN page.

AV Streaming and Interoperability Overview

To provide the Media Center experience remotely, the Extender needs a way to interact with the Media Center PC to establish the correct connection parameters. This interaction helps the Extender understand what action the customer would like completed, and to send possible errors back to the PC.

Media Center PC

To understand the Extender remote AV playback infrastructure, it helps to understand how Media Center operates locally.

When a customer wants to play media, the request is received by the Media Center shell. Then, it is handled by ehPlayer, which exposes and implements an interface derived from the Iplayer interface. The purpose of this component is to interact with MSVidCtl to build the appropriate DirectShow graph and provide the desired experience, as shown in Figure 3.

Request flow from Media Center Extender

Figure 3: Request flow from Media Center Extender

To render media content on the Extender, the media content and associated control information must be sent to the Extender.

Control Information

When the Extender is playing the AV stream, ehRemotePlayer is inserted between ehShell and ehPlayer. It acts as a proxy, delivering relevant distribution information to the Extender. The ehRemotePlayer has two key functions:

  • Implements the Iplayer interface and serves as the shim between ehShell and ehPlayer, forwarding requests from ehShell to ehPlayer, and then relaying the applicable information to the Extender through the Media Center Proxy (MRProxy). All remote networking communication with the Extender is encapsulated by MRProxy (MRProxy does not perform any processing on its own).
  • Receives communication from ehPlayer about state changes and relays them to ehShell.

    Control flow for Media Center Extender

Figure 4: Control flow for Media Center Extender

Media Content

AV content is sent to Media Center Extender by replacing the rendering portion of the DirectShow graph in the VidCtl with NetSink. NetSink is responsible for accepting AV streams within the DirectShow graph and sending them out over the network to the Extender.

Client

On the client side, both the AV and control information are fed into the MediaReceiver. The AV stream is sent as packets across the network. The MediaReceiver unpacks the incoming AV stream and delivers it to the Extender, as well as performing control operations, such as transport control.

The Media Device Model (MDM) is a device-rendering architecture that is designed to be used in a system that delivers synchronized AV streaming over an IP-based network. While the current Media Center AV system design uses the network as the transport of AV streams, MDM is not limited exclusively to this use.

At the lowest level, MDM is an object model of the hardware components typically found on highly integrated system processors used in consumer electronic devices for use with the digital TV set-top box market. While best suited for chipsets that employ direct memory access (DMA) and hardware accelerated decoding, MDM is abstract enough to be used in devices, including a PC, that use a powerful Complex Instruction Set Computer (CISC) processor using software to expose AV functionality. MDM is designed to be portable by requiring only a few basic kernel operating system primitives such as threads, events, locks, and memory allocation to execute.

To understand the MDM architecture it is important to understand the way MDM fits into the overall Media Center AV systems architecture. Within the Media Center Extender AV system, MDM can be thought of as the final output segment of the streaming pipeline. At its lowest layer, it talks directly to the hardware to accelerate the decoding and rendering of the AV stream.

Architecture of audio and video playback