DirectShow
From Free net encyclopedia
DirectShow (sometimes abbreviated as DS or DShow), codename Quartz, is an application programming interface produced by Microsoft for software developers to perform various operations with media files. It is a replacement for Microsoft's earlier Video for Windows technology. Based on the Microsoft Windows Component Object Model framework, DirectShow provides a common interface for media across many of Microsoft's Programming Languages, and is an extensible, filter-based framework that can render or record media files on demand at the behest of the user or developer. The DirectShow development tools and documentation are distributed as part of the Microsoft Platform SDK.
Applications such as Windows Media Player use DirectShow or a variation thereof to display content from a file or URL. DirectShow's most notable competition is Apple Computer's QuickTime framework.
Contents |
History
ActiveMovie, codename Quartz, the predecessor of DirectShow, was started in the Windows 3.0 days by Geraint Davies for Microsoft as an answer to QuickTime, the most popular media platform at the time. ActiveMovie was first available as an add-on to Windows 95 and that required Internet Explorer 3.0. Its main purpose at the time was to serve as a plugin for Internet Explorer to play media files inside of its window(s), such as what QuickTime offered for Netscape and Internet Explorer at the time, and to serve as a replacement for Video for Windows, particularly for MPEG files whose frame-reordering was difficult to deal with in Video for Windows.
In 1998, around the time of DirectX 5's release, ActiveMovie was renamed to DirectShow (reflecting Microsoft's efforts at the time to consolidate technologies that worked "directly" with hardware under a common naming scheme) and was included part of the "DirectMedia SDK". In version 7 of DirectX, DirectShow became part of the mainline distribution of the DirectX SDK and given its own place alongside other DirectX APIs such as DirectInput. Even then, DirectShow was mostly used as a way to receive data from video input devices, such as a camcorder, and the ability of it to render data from a file was mostly used by Windows Media Player.
As of April 2005, DirectShow was removed from DirectX and moved to the Microsoft Platform SDK instead. The DirectX SDK is, however, still required to build DirectShow samples.<ref name="dsmustdx>Template:Cite web</ref>
Design Model
The way DirectShow works usually is that a developer creates a filter graph, adds some filters – possibly custom – to the graph, and then renders a file, URL or camera. During the rendering process, the filter graph searches the Windows Registry for registered filters and builds its graph of filters based on the location provided. After this, it connects the filters together, and, at the developer's request, plays/pauses etc. the created graph.
Each filter represents a stage in the processing of the data, e.g. reading from a file or camera, decoding, transforming or rendering. The filter has a number of pins that represent connection points on the filter that can be connected to other filters. Pins can be either output or input. Depending on the filter, data is either "pulled" from an output pin or "pushed" to an input pin in order to transfer data between filters.
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's usually easier to stop the graph and create a new graph from scratch.
Features
There are several levels of abstraction available in rendering sources in DirectShow, and doing any of these is fairly simple to do as long a custom filter isn't needed. At the most basic level, the procedure is for the developer to build a filter graph from scratch by manually adding and connecting each desired filter in the graph. The procedure for the next level of complexity is for the developer to create his or her own filter graph, for example from a source filter that contains information about a file or website address (URL) and possibly some custom filter that the user would desire, and then to let DirectShow complete the filter graph for the user and connect the filters together. Finally, the developer could just let DirectShow create a filter graph for him or her automatically from a source such as a file or URL.
By default, DirectShow supports several common media file formats, such as MP3,<ref name="mp3note">While DirectShow can play VBR MP3s, it cannot seek accurately or perform many other functions correctly in them due to incorrect parsing of the file (possibly due to incorrect parsing of the XING header). The Windows Media Player 10 SDK and later versions of windows media player do this correctly, however.</ref> and Windows Media Video as well as several more mundane formats, such as plain static images.<ref name="formats">Template:Cite web</ref> Since the technology is licensed in Windows, no payout to Fraunhofer is required for say, an MP3 license. Extensions allow DirectShow to be extended to support any format available; for example, there have been filters made for Ogg Vorbis files<ref name="ovfilter">Template:Cite web</ref> and AC3, and a number of others.
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. Recent developments in QuickTime (including an ActiveX Control) have lessened this, however.
Criticism
While playing a file is relatively simple task, more custom things like receiving certain windows messages from the video window or creating custom filters, developers invariably encounter the dark side of the DirectShow API. DirectShow is infamous for its complexity and is often regarded by many people as one of Microsoft's most complex development libraries/APIs. A long-running semi-joke on the "Microsoft.public.win32.programmer.directx.video" newsgroup is "see you in 6 months" whenever someone wants to develop a new filter for DirectShow.
Developers rarely directly create DirectShow filters - they usually use a set of MFC-like (although not requiring MFC) classes called the "DirectShow Base Classes" that the developer will generally use that take care of most of the dirty work. The size of the base classes is nearly half the size, in code, of the entire MFC library. Even with the base classes, the sheer number of COM objects DirectShow has is immense, and can overwhelm some developers who want to develop what they may have thought to be something fairly straightforward. DirectShow's API sometimes breaks traditional COM rules in some aspects, such as in regards to parameters to methods, although those are usually documented. So, to counter these situations, developers often use a higher level API that uses DirectShow itself, namely the Windows Media Player SDK, which provides an ActiveX Control that has fewer COM interfaces to deal with.
DirectShow has also been criticized for its support of Digital Rights Management. However, it is merely a figurehead in this case as DirectShow itself has minimal support for DRM in the API. The real "villain" in this case is in fact the Windows Media Player SDK which is distributed separately from DirectShow and is where most of the support for DRM lies. In the same vein, DirectShow is also criticized for restricting the ability of third-party media players, that is to say, media players other than Windows Media Player, to play media files. For example, after a settlement with the European Union Microsoft started shipping a version of Windows that did not include Windows Media Player, and while all of DirectShow's default formats<ref name="formats"/> appear to be supported some of Microsoft's statements during the time alluded that the stripped-down versions of the operating system could be unable to support some of those formats.<ref name="EU ruling 1">Template:Cite web</ref>
Video Renderer vs. VMR7 vs. VMR9
Template:Divbox Case in point to the complexity argument – originally the way to play video was to use the Video Renderer filter. This drew the images using DirectDraw, but could also fall back to GDI drawing in some circumstances. One problem with it was limited access to the window: Video for Windows had been plagued with deadlocks caused by applications' incorrect handling of the video window, so in early DirectShow releases, the handle to the playback window was hidden from applications. This of course made it very difficult for sophisticated applications to handle Windows messages, such as WM_SETCURSOR<ref name="ivwhandlenote">This is not entirely true, as some clever people found that the EnumChildWindows API could be called on the owner window of the IVideoWindow and then steal its WndProc messages directly.</ref>. There was also no reliable way to draw caption text or graphics on top of the video.
Windows XP introduced a new filter called VMR-7<ref name="VMR-7">Template:Cite web</ref> (Abbreviation for Video Mixing Renderer 7, sometimes just referred to as plain VMR). The 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, so allowing applications to draw text and graphics over the video. VMR7 also featured a "windowless mode"<ref name="windowless mode">Template:Cite web</ref> which fixed the problems with access to the window handle; however it required a bit of extra initialization code. For non-technical reasons, it was released only on Windows XP.<ref name="VMR7note">Some people have noted that it "unofficially" works on Windows 2000 also: owing to a build error, some of the DirectX runtime packages for Windows 2000 accidentally included VMR-7.</ref>
DirectX 9 included yet another renderer, dubbed VMR-9.<ref name="VMR-9">Template:Cite web</ref> This version depends on DirectX9-style graphics (a.k.a. Direct3D). Unlike the VMR-7, it also would work on any system that supported DirectX9, provided that the graphics adapter could support the required Direct3D modes. However, this caused even further splintering on an already extremely involved API.
References
- Template:Cite web
- Template:Cite book (Sample Chapter)
- Various posts from the "Microsoft.public.win32.programmer.directx.video" newsgroup
Notes
<references/>
External links
- MSDN - 'Official DirectShow documentation from MSDN'
- MSDN - 'DirectShow Downloads from MSDN'
- Home page of Geraint Davies - 'Creator of DirectShow and a DirectShow MVP – Contains several FAQs and examples.'
- The March Hare - 'Prolific DirectShow MVP – Contains several FAQs'
- Chris P's code - 'Another DirectShow MVP – Some samples focused on audio.'
- AV Programming Forum - 'Articles and Forum for DirectShow and Format SDK.'
- RadLight - 'Theora DirectShow filter enables Microsoft Windows Media Player to play Theora videos.'
- Illiminable - 'Open source Directshow filter for Ogg Vorbis, Speex, Theora and FLAC for Windows Media Player. The source code, available from the xiph.org Subversion repository, contains implementations of more than 15 different DirectShow filters.'pt:DirectShow