簡介
DirectShow是微軟公司提供的一套在Windows平台上進行流媒體處理的開發包，9.0之前與DirectX開發包一起發布，之後包含在windowsSDK中。
運用DirectShow，我們可以很方便地從支持WDM驅動模型的采集卡上捕獲數據，并且進行相應的後期處理乃至存儲到文件中。它廣泛地支持各種媒體格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等等，使得多媒體數據的回放變得輕而易舉。另外，DirectShow還集成了DirectX其它部分（比如DirectDraw、DirectSound）的技術，直接支持DVD的播放，視頻的非線性編輯，以及與數字攝像機的數據交換。
曆史
ActiveMovie，開發代号Quartz，這個由GeraintDavies為微軟公司設計的DirectShow的前身，在Windows3.0時代，是作為一種對當時最流行的媒體平台QuickTime的回應而開發的。ActiveMovie最早的出現是被附加在Windows95上面的并且需要系統安裝了IE3.0。它當時的使命是作為IE的附件播放在其窗口内的媒體文件，正如當時QuickTime為Netscape以及IE提供的服務那樣，它的另一個功能是作為Windows視頻技術（VFW，VideoForWindows）的一個替換，特别地為在VFW架構中難于處理的MPEG（移動圖象專家組格式文件）文件提供輔助處理。
在1998年，大緻在DirectX5年代的時候，ActiveMovie被重命名為DirectShow（反映了微軟公司在那時正在努力加強“直接地”在一個通常的取名系統之下與硬件合作的技術）并且被包含為"DirectMediaSDK"的一部份。在DirectX的7版中，DirectShow變成了DirectXSDK主要組成部分而且如同DirectInput等其它DirectXAPIs一樣被給予了它自己的位置。甚至之後，DirectShow被主要用來接收來自像一個手提攝像機這樣的電視輸入裝置的數據，而且它從文件中顯示數據的能力被廣泛用在WindowsMediaPlayer上面。
從2005年四月起，DirectShow被從DirectXSDK移除，必須單獨下載Extra包才能得以支持，之後DirectShow的文檔和示例被轉移到WindowsSDK，DirectShow也正式成為Windows的一個組件。然而，在編譯某些DirectShow的示例時，DirectXSDK仍然是必需的。
設計
DirectShow運行的方式通常是一個開發者創建一個FilterGraph，把一些Filter-可能訂制-加入FilterGraph，然後播放文件，或者播放來自互聯網或照相機的數據。當播放進程運行時，FilterGraph在Windows注冊中尋找注冊了的Filters并且為這些Filter創建本地提供的Graph。在這之後，它将所有的Filter連接在一起，并且在開發者的請求下，播放/中止創造的Graph。
為一個mp3文件創建的Filtergraph，由DirectShow自帶的示例GraphEdit來播放。在這幅圖中大的方塊代表Filtergraph，小的方塊代表端口。每個Filter表示數據處理過程的一個階段，舉例來說從一個文件或照相機讀取數據，解碼，轉換以及繪制。filter有若幹的能被連接到其他filter上的連接點的Interface。Interface可能是輸出或輸入。根據filter，數據被采用“拉模式”從輸出端口輸出，或者以“推模式”被推到另一個輸入端口，并借此來傳輸數據。大多數filters的創建使用了一組DirectShowSDK提供的C++類，叫做DirectShowBaseClass。
這些為filters解決了許多創建，注冊和連接的問題。如果要讓filtergraph能夠自動的使用filters，它們需要在一個分開的DirectShow項目中被登記并與COM一起登記。這一個注冊能被DirectShowBaseClass處理。然而，如果應用程序手工增加filters，他們不需要被全然登記。不幸地，它難以修改一個正在運行中的graph。從頭停止graph而産生一個新graph通常是比較容易的。
功能
在DirectShow中有許多抽象的播放源文件的方法，實現這些功能也是相當簡單的而且不需要一個定制過的filter。下一步相對複雜的過程是程序開發員需要開發他（她）自己的filtergraph，舉個例子他們可能設計一個可以接受來自互聯網或是硬盤文件數據的sourcefilter，也許有些定制的filter就是開發者想要的，接下來他們需要讓DirectShow為用戶完成一個filterGraph并将所有filter連接起來，在最後開發者僅僅隻用讓DirectShow為他們生成一個可以獲取文件數據的sourcefilter就可以了。
DirectShow預先設置支持許多通常的媒體格式，如MP3，和Windows媒體視頻和一些比較常見的格式，比如簡單的靜态圖像。自從在Windows中這些技術被許可了，對Fraunhofer來說就沒有為專利權而付出花費的必要了，比如MP3執照。擴充機制允許DirectShow在将來可以支持出現的任何格式，舉例來說，已經有對OggVorbis文件和AC3文件的支持filters，此外還有若幹其它的支持filters。
不同于為了讀取媒體文件必須在循環中需要調用MoviesTask的為QuickTime設計的mainCAPI，DirectShow以一種透明的方式處理這個問題。它在後台創建了一些線程來平緩的播放這些來自文件和互聯網的數據與此同時不需要程序做很多任務作。還跟QuickTime正好相反的是，在讀取一段來自互聯網數據而不是讀取硬盤文件的時候沒有特别的需要——DirectShow的filtergraph摘錄了來自程序的這些明細。然而，QuickTime（包括一個ActiveX控制）在這方面的發展相比之下遜色很多。
評價
播放一個文件是一項相對簡單的任務，不過對于像是從視頻窗口接收特定窗口信息到創建特定filters，開發者會不斷地遇到DirectShowAPI的黑暗面。DirectShow因其複雜性而聲名狼借與此同時很多人認為它是微軟最複雜的libraries/APIs。在“Microsoft.public.win32.programmer.directx.video”新聞群組上存在一個長期的灰色笑話，講的是每當某人想要為DirectShow開發一個新的filter時，那麼“六個月後見吧”。
開發者很少直接創建DirectShowfilters他們通常使用被稱為“DirectShow基礎類”的一組像MFC一樣的（不需要MFC）類别而開發者通常将會使用這些類來處理大多數工作。基本類的大小幾乎是在代碼中整個MFClibrary類大小的一半。即使有了基本類，DirectShow中存在的COM對象的絕對數量也是巨大的，甚至可以颠複那些開發者想要開發的那種本以為相當直接的東西。DirectShow's的API有時違反一些傳統的COM規則，比如關于關于參數到方法，雖然那些通常被證明了的。
因此，為了制止這些情形，開發者時常使用DirectShow本身中較高層次的API，即WindowsMediaPlayerSDK，它提供了一個有較少COM接口處理的ActiveX控制。DirectShow也因它對數據管理權限的支持而受到批評。然而當DirectShow本身有的API對DRM隻有最小支持的時候，它在這情況隻是一個名義上的領導者。
在這個案例中真正的“壞人”事實上是被從DirectShow分開的WindowsMediaPlayerSDK因為它是對DRM有最多支持的地方。在相同方面，DirectShow也因對第三方媒體播放器功能的限制而受到指責，也就是說，在播放媒體文件方面，對WindowsMediaPlayer以外的媒體播放器存在不公。
