Sticking to Standard Technologies
[This is preliminary documentation and subject to change.]
Wherever possible, Broadcast Architecture software relies on standard solutions that are widely accepted, understood, and supported in the industry. These standards include:
-
The Transmission Control Protocol/Internet Protocol (TCP/IP) networking protocol. This protocol is the one used by the Internet. By using TCP/IP as their primary networking protocol, broadcast clients make a standard way available to communicate with virtually any network in the world.
-
MPEG-2 compression. This format is becoming the most widely accepted standard for delivering compressed video and audio and related data.
-
The Microsoft® Windows® 98 operating system. In addition to being the successor to the most widely used and understood 32-bit operating system, Microsoft® Windows® 95, Windows 98 includes a number of components that are becoming or have become standards themselves:
-
Windows Sockets (WinSock) version 2.0. This application programming interface (API) provides a network abstraction layer that allows applications to receive and send network data without needing any information about the network involved. WinSock also provides access to TCP/IP.
-
Network Driver Interface Specification (NDIS) version 5.0 ports. The NDIS standard allows hardware device drivers to be written independently of the target operating system.
-
CryptoAPI. This API provides an abstraction layer for encryption and decryption services, so that applications can use different encryption methods without requiring any information about the hardware or software involved.
-
Microsoft® Internet Explorer. By incorporating Internet Explorer technology, the broadcast client can take advantage of all the latest Internet and Web enhancements.
-
Component Object Model (COM). This open standard allows different software modules, written without information about each other, to work together as if they were part of the same program.
-
Microsoft DirectShow (formerly called Microsoft® ActiveMovie™). This Microsoft® ActiveX® technology provides an extremely flexible and capable architecture for managing and playing interrelated multimedia streams, which the broadcast client relies on. The key concept of the Microsoft® DirectShow™ API is to connect many independent filter programs together. Each filter handles a part of the process of receiving, decoding, transforming, scheduling, and displaying interdependent video, audio, and data streams.
-
Key codes for television remote controls. The remote control buttons included on keyboards and other devices communicate with broadcast clients by using standard Windows key codes. Use of standard key codes makes integration of remote functions into hardware very simple for manufacturers.
The DirectShow technology and the related stream class driver technology, part of the Windows Driver Model (WDM), is sufficiently important for broadcast clients that its flexibility should be stressed. DirectShow filters are modular software components that work together to process a data stream. When one feature of the stream changes, only the filter dealing with that feature need be replaced. For example, if a stream's encoding changes, only its decoding filter is affected. This modularity makes it easy to use and support clients that work with virtually any kind of broadcast possible.
To get the maximum performance, Broadcast Architecture supports DirectShow by using WDM stream class drivers. These drivers operate on data in kernel mode. DirectShow provides control of these drivers to applications through the use of proxy filters running in user mode. For example, an application can call a proxy filter in DirectShow to change channels on a television tuner card. Then the proxy filter calls the WDM stream class driver, which controls the television tuner card.
To locate more information on how to create and use new DirectShow filters to handle changing technologies, and on WDM stream class drivers and filters, see Further General Information.