DirectShow

Architecture

DirectShow divides a complex multimedia task (e.g. video playback) into a sequence of fundamental processing steps known as filters. Each filter – which represents one stage in the processing of the data – has input and/or output pins that may be used to connect the filter to other filters. The generic nature of this connection mechanism enables filters to be connected in various ways so as to implement different complex functions. To implement a specific complex task, a developer must first build a filter graph by creating instances of the required filters, and then connecting the filters together.

There are three main types of filters:

Source filters

These provide the source streams of data. For example, reading raw bytes from any media file.

Transform filters

These transform data that is provided from other filter's output. For example, doing a transform such as adding text on top of video or uncompressing an MPEG frame.

Renderer filters

These render the data. For example, sending audio to the sound card, drawing video on the screen or writing data to a file.

During the rendering process, the filter graph searches the Windows Registry for registered filters and builds its graph of filters based on the locations provided. After this, it connects the filters together, and, at the developer's request, executes (i.e., plays, pauses, etc.) the created graph. DirectShow filter graphs are widely used in video playback (in which the filters implement functions such as file parsing, video and audio demultiplexing, decompressing and rendering) as well as for video and audio recording, editing, encoding, transcoding or network transmission of media. Interactive tasks such as DVD navigation may also be controlled by DirectShow.

In the above example, from left to right, the graph contains a source filter to read an MP3 file, stream splitter and decoder filters to parse and decode the audio, and a rendering filter to play the raw audio samples. Each filter has one or more pins that can be used to connect that filter to other filters. Every pin functions either as an output or input source for data to flow from one filter to another. Depending on the filter, data is either "pulled" from an input pin or "pushed" to an output pin in order to transfer data between filters. Each pin can only connect to one other pin and they have to agree on what kind of data they are sending.

Most filters are built using a set of C++ classes provided in the DirectShow SDK, called the DirectShow Base Classes. These handle much of the creation, registration and connection logic for the filter. For the filter graph to use filters automatically, they need to be registered in a separate DirectShow registry entry as well as being registered with COM. This registration can be managed by the DirectShow Base Classes. However, if the application adds the filters manually, they do not need to be registered at all. Unfortunately, it is difficult to modify a graph that is already running. It is usually easier to stop the graph and create a new graph from scratch. Starting with DirectShow 8.0, dynamic graph building, dynamic reconnection, and filter chains were introduced to help alter the graph while it was running. However, some filter vendors ignore this feature, making graph modification problematic after a graph has begun processing.

Although DirectShow is capable of dynamically building a graph to render a given media type, in certain instances it is difficult for developers to rely on this functionality and they need to resort to manually building filter graphs if the resulting filter graph is variable. It is possible for filter graphs to change over time as new filters are installed on the computer.

Features

By default, DirectShow includes a number of filters for decoding some common media file formats such as MPEG-1, MP3, Windows Media Audio, Windows Media Video, MIDI, media containers such as AVI, ASF, WAV, some splitters/demultiplexers, multiplexers, source and sink filters, some static image filters, some video acceleration, and minimal digital rights management (DRM) support. DirectShow's standard format repertoire can be easily expanded by means of a variety of filters, enabling DirectShow to support virtually any container format and any audio or video codec. For example, filters have been developed for Ogg Vorbis, Musepack, and AC3, and some codecs such as MPEG-4 Advanced Simple Profile, AAC, H.264, Vorbis and containers MOV, MP4 are available from 3rd parties like ffdshow, K-Lite, and CCCP. Incorporating support for additional codecs such as these can involve paying the licensing fees to the involved codec technology developer or patent holder. Finally, there are "bridge" filters that simultaneously support multiple formats, as well as functions like stream multiplexing, by exposing the functionality of underlying multimedia APIs such as VLC.

The amount of work required to implement a filter graph depends on several factors. In the simplest case, DirectShow can create a filter graph automatically from a source such as a file or URL. If this is not possible, the developer may be able to manually create a filter graph from a source file, possibly with the addition of a custom filter, and then let DirectShow complete the filter graph by connecting the filters together. At the next level, the developer must build the filter graph from scratch by manually adding and connecting each desired filter. Finally, in cases where an essential filter is unavailable, the developer must create a custom filter before a filter graph can be built.

Unlike the main C API of QuickTime where it is necessary to call MoviesTask in a loop to load a media file, DirectShow handles all of this in a transparent way. It creates several background threads that smoothly play the requested file or URL without much work required from the programmer. Also in contrast to QuickTime, nothing special is required for loading a URL instead of a local file on disk – DirectShow's filter graph abstracts these details from the programmer, although recent developments in QuickTime (including an ActiveX control) have reduced this disparity.

GraphEdit

GraphEdit is a visual tool for building and testing filter graphs for DirectShow. Filters are displayed as boxes, with a text caption showing the name of the filter. GraphEdit can be used to prototype DirectShow filter graphs.

DirectShow Editing Services

DirectShow Editing Services (DES), introduced in DirectX 8.0/Windows XP is an API targeted at video editing tasks and built on top of the core DirectShow architecture. DirectShow Editing Services was introduced for Microsoft's Windows Movie Maker. It includes APIs for timeline and switching services, resizing, cropping, video and audio effects, as well as transitions, keying, automatic frame rate and sample rate conversion and such other features which are used in non-linear video editing allowing creation of composite media out of a number of source audio and video streams. DirectShow Editing Services allow higher-level run-time compositing, seeking support, and graph management, while still allowing applications to access lower-level DirectShow functions.

While the original API is in C++, DirectShow Editing Services is accessible in any Microsoft .NET compatible language including Microsoft Visual C# and Microsoft Visual Basic by using a third-party code library called "DirectShowNet Library". Alternatively, the entire DirectShow API, including DirectShow Editing Services, can be accessed from Borland Delphi 5, 6 and 7, C++ Builder 6, and from later versions with a few minor modifications, using a third party software library called "DSPack".

As of March, 2012 (and, apparently as early as 2009), Microsoft has stated that the DirectShow Editing Services "API is not supported and may be altered or unavailable in the future."

Video rendering filters

Originally, in Windows 9x, DirectShow used the Video Renderer filter. This drew the images using DirectDraw 3, but could also fall back to GDI or overlay drawing modes in some circumstances (depending upon the visibility of the video window and the video card's capabilities). It had limited access to the video window. Video for Windows had been plagued with deadlocks caused by applications' incorrect handling of the video windows, so in early DirectShow releases, the handle to the playback window was hidden from applications. There was also no reliable way to draw caption text or graphics on top of the video.

DirectShow 6.0, released as part of DirectX Media introduced the Overlay Mixer renderer designed for DVD playback and broadcast video streams with closed captioning and subtitles. The Overlay Mixer uses DirectDraw 5 for rendering. Downstream connection with the Video Renderer is required for window management. Overlay Mixer also supports Video Port Extensions (VPE), enabling it to work with analog TV tuners with overlay capability (sending video directly to a video card via an analog link rather than via the PCI bus). Overlay Mixer also supports DXVA connections. Because it always renders in overlay, full-screen video to TV-out is always activated.

DirectX 7.0 and Windows 2000 had introduced DXVA 1.0. DXVA 1.0 is usually based on more reliable WDM graphics drivers; on DirectX 7.0 and later, DirectShow is a backward compatible API of DXVA.

Starting with Windows 2000, a new filter called the Video Mixing Renderer 7 (VMR-7 or sometimes just referred to as VMR) was introduced. The number 7 was because VMR-7 only used DirectDraw version 7 to render the video and did not have the option to use GDI drawing. The main new feature of VMR-7 was the ability to mix multiple streams and graphics with alpha blending, allowing applications to draw text and graphics over the video and support custom effects. It also featured a "windowless mode" (access to the composited image before it is rendered) which fixed the problems with access to the window handle.

DirectX 9 introduced VMR-9, which is included in Windows XP SP2 and newer. This version uses Direct3D 9 instead of DirectDraw, allowing developers to transform video images using the Direct3D pixel shaders. It is available for all Windows platforms as part of the DirectX 9 redistributable. As VMR-7 it provides a Windowless Mode. However, unlike Overlay mixer or VMR-7 it does not support video ports. Using the /3GB boot option may cause VMR-9 to fail.

Windows Vista and Windows 7 ship with a new video renderer, available as both a Media Foundation component and a DirectShow filter, called the Enhanced Video Renderer (EVR). EVR is designed to work with Desktop Window Manager and supports DXVA 2.0, which is available on Windows Vista and Windows 7. It offers better performance and better quality according to Microsoft. On Windows Vista, its multimedia framework was rewritten; only video decoding is hardware-accelerated, audio decoding (such as MP3) is CPU-based.

Reception

Awards

On January 8, 2007. Microsoft received the Emmy award for Streaming Media Architectures and Components at the 58th Annual Technology & Engineering Emmy Awards.

Simplicity

Commanding DirectShow to play a file is a relatively simple task. However, while programming more advanced customizations, such as commanding DirectShow to display certain windows messages from the video window or creating custom filters, multiple developers complain of difficulties. It is regarded as one of Microsoft's most complex development libraries/APIs.

Developers rarely create DirectShow filters from scratch. Rather, they employ DirectShow Base Classes. The Base Classes can often simplify development, allowing the programmer to bypass certain tasks. However, the process may remain relatively complex; the code found in the Base Classes is nearly half the size of the entire MFC library. As a result, even with the Base Classes, the number of COM objects that DirectShow contains often overwhelms developers. In some cases, DirectShow's API deviates from traditional COM rules, particularly with regard to the parameters used for methods. To overcome their difficulties with DirectShow's unique COM rules, developers often turn to a higher level API that uses DirectShow, notably, Windows Media Player SDK, an API provides the developer with an ActiveX Control that has fewer COM interfaces to deal with.

Although DirectShow is capable of dynamically building a graph to render a given media type, in certain instances it is difficult for developers to rely on this functionality and they need to resort to manually building filter graphs if the resulting filter graph is variable. It is possible for filter graphs to change over time as new filters are installed on the computer.

Codec hell

Codec hell (a term derived from DLL hell) is when multiple DirectShow filters conflict for performing the same task. A large number of companies now develop codecs in the form of DirectShow filters, resulting in the presence of several filters that can decode the same media type. This issue is further exacerbated by DirectShow's merit system, where filter implementations end up competing with one another by registering themselves with increasingly elevated priority.

Microsoft's Ted Youmans explained that "DirectShow was based on the merit system, with the idea being that, using a combination of the filter’s merit and how specific the media type/sub type is, one could reasonably pick the right codec every time. It wasn't really designed for a competing merit nuclear arms race."

A tool to help in the troubleshooting of "codec hell" issues usually referenced is the GSpot Codec Information Appliance, which can be useful in determining what codec is used to render video files in AVI and other containers. GraphEdit can also help understanding the sequence of filters that DirectShow is using to render the media file. Codec hell can be resolved by manually building filter graphs, using a media player that supports ignoring or overriding filter merits, or by using a filter manager that changes filter merits in the Windows Registry.

End-user tools

DirectShow, being a developer-centric framework and API, does not directly offer end-user control over encoding content, nor does it incorporate a user interface for encoding using installed codecs or to different formats; instead, it relies on developers to develop software using the API. In contrast, other multimedia frameworks such as QuickTime or Video for Windows allow end-users to perform basic video-related tasks such as re-encoding using a different codec and editing files and streams. The convenience offered by an end-user GUI is apparent since the AVI format and codecs used by Video for Windows still remain in use, for example VirtualDub.