DirectShow

DirectShow是微軟公司提供的一套在Windows平台上進行流媒體處理的開發包，9.0之前與DirectX開發包一起發佈，之後包含在windows SDK中。

運用DirectShow，我們可以很方便地從支持WDM驅動模型的採集卡上捕獲數據，並且進行相應的後期處理乃至存儲到文件中。它廣泛地支持各種媒體格式，包括Asf、Mpeg、Avi、Dv、Mp3、Wave等等，使得多媒體數據的回放變得輕而易舉。另外，DirectShow還集成了DirectX其它部分（比如DirectDraw、DirectSound）的技術，直接支持DVD的播放，視頻的非線性編輯，以及與數字攝像機的數據交換。

ActiveMovie，開發代號 Quartz， 這個由 Geraint Davies 為微軟公司設計的 DirectShow 的前身，在 Windows 3.0 時代，是作為一種對當時最流行的媒體平台 QuickTime 的迴應而開發的。ActiveMovie 最早的出現是被附加在 Windows 95 上面的並且需要系統安裝了 IE3.0 。它當時的使命是作為 IE 的附件播放在其窗口內的媒體文件，正如當時 QuickTime 為 Netscape 以及 IE 提供的服務那樣，它的另一個功能是作為 Windows 視頻技術（VFW，Video For Windows）的一個替換，特別地為在 VFW 架構中難於處理的 MPEG（移動圖象專家組格式文件）文件提供輔助處理。

在 1998 年，大致在 DirectX 5 年代的時候，ActiveMovie 被重命名為 DirectShow（反映了微軟公司在那時正在努力加強“直接地”在一個通常的取名系統之下與硬件合作的技術）並且被包含為 " DirectMedia SDK" 的一部份。在 DirectX 的 7 版中，DirectShow 變成了 DirectX SDK 主要組成部分而且如同 DirectInput 等其它 DirectX APIs 一樣被給予了它自己的位置。甚至之後， DirectShow 被主要用來接收來自像一個手提攝像機這樣的電視輸入裝置的數據，而且它從文件中顯示數據的能力被廣泛用在 Windows Media Player 上面。 從 2005 年四月起，DirectShow 被從 DirectX SDK 移除，必須單獨下載Extra包才能得以支持，之後DirectShow的文檔和示例被轉移到Windows SDK，DirectShow也正式成為Windows的一個組件。然而，在編譯某些 DirectShow 的示例時，DirectX SDK 仍然是必需的。

DirectShow 運行的方式通常是一個開發者創建一個 Filter Graph，把一些 Filter - 可能訂製 - 加入 Filter Graph，然後播放文件，或者播放來自互聯網或照相機的數據。當播放進程運行時，Filter Graph 在 Windows 註冊中尋找註冊了的 Filters 並且為這些 Filter 創建本地提供的 Graph 。在這之後，它將所有的 Filter 連接在一起，並且在開發者的請求下，播放/中止創造的Graph。

為一個 mp3 文件創建的 Filter graph，由 DirectShow 自帶的示例 GraphEdit 來播放。在這幅圖中大的方塊代表 Filter graph ，小的方塊代表端口。 每個Filter表示數據處理過程的一個階段，舉例來説從一個文件或照相機讀取數據，解碼，轉換以及繪製。filter 有若干的能被連接到其他 filter 上的連接點的Interface。Interface可能是輸出或輸入。根據 filter，數據被採用“拉模式”從輸出端口輸出，或者以“推模式”被推到另一個輸入端口，並藉此來傳輸數據。 大多數 filters 的創建使用了一組 DirectShow SDK 提供的 C++類，叫做 DirectShow BaseClass。這些為 filters 解決了許多創建，註冊和連接的問題。如果要讓 filter graph 能夠自動的使用 filters，它們需要在一個分開的 DirectShow 項目中被登記並與 COM 一起登記。 這一個註冊能被 DirectShow BaseClass處理。然而，如果應用程序手工增加 filters，他們不需要被全然登記。 不幸地，它難以修改一個正在運行中的 graph 。從頭停止 graph 而產生一個新 graph 通常是比較容易的。

在 DirectShow 中有許多抽象的播放源文件的方法，實現這些功能也是相當簡單的而且不需要一個定製過的 filter 。下一步相對複雜的過程是程序開發員需要開發他（她）自己的 filter graph ，舉個例子他們可能設計一個可以接受來自互聯網或是硬盤文件數據的 source filter ，也許有些定製的 filter 就是開發者想要的，接下來他們需要讓 DirectShow 為用户完成一個 filter Graph 並將所有 filter 連接起來，在最後開發者僅僅只用讓 DirectShow 為他們生成一個可以獲取文件數據的 source filter 就可以了。

DirectShow 預先設置支持許多通常的媒體格式，如 MP3，和 Windows 媒體視頻和一些比較常見的格式，比如簡單的靜態圖像。自從在 Windows 中這些技術被許可了，對 Fraunhofer 來説就沒有為專利權而付出花費的必要了，比如 MP3 執照。擴充機制允許 DirectShow 在將來可以支持出現的任何格式，舉例來説，已經有對 Ogg Vorbis 文件和 AC3 文件的支持 filters ，此外還有若干其它的支持 filters 。

不同於為了讀取媒體文件必須在循環中需要調用 MoviesTask 的為 QuickTime 設計的 main C API ，DirectShow 以一種透明的方式處理這個問題。它在後台創建了一些線程來平緩的播放這些來自文件和互聯網的數據與此同時不需要程序做很多任務作。還跟 QuickTime 正好相反的是，在讀取一段來自互聯網數據而不是讀取硬盤文件的時候沒有特別的需要——DirectShow 的 filter graph 摘錄了來自程序的這些明細。然而，QuickTime（包括一個 ActiveX 控制）在這方面的發展相比之下遜色很多。

播放一個文件是一項相對簡單的任務，不過對於像是從視頻窗口接收特定窗口信息到創建特定 filters，開發者會不斷地遇到 DirectShow API 的黑暗面。 DirectShow 因其複雜性而聲名狼藉與此同時很多人認為它是微軟最複雜的libraries/APIs。在“Microsoft.public.win32.programmer.directx.video”新聞羣組上存在一個長期的灰色笑話，講的是每當某人想要為 DirectShow 開發一個新的 filter 時，那麼“六個月後見吧”。

開發者很少直接創建 DirectShow filters - 他們通常使用被稱為“ DirectShow 基礎類”的一組像 MFC 一樣的（不需要 MFC）類別而開發者通常將會使用這些類來處理大多數工作。 基本類的大小几乎是在代碼中整個 MFC library類大小的一半。 即使有了基本類，DirectShow 中存在的 COM 對象的絕對數量也是巨大的，甚至可以顛覆那些開發者想要開發的那種本以為相當直接的東西。 DirectShow's 的 API 有時違反一些傳統的 COM 規則，比如關於參數到方法，雖然那些通常被證明了的。因此，為了制止這些情形，開發者時常使用 DirectShow 本身中較高層次的 API，即 Windows Media Player SDK，它提供了一個有較少 COM 接口處理的 ActiveX 控制。 DirectShow 也因它對數據管理權限的支持而受到批評。然而當 DirectShow 本身有的 API 對 DRM 只有最小支持的時候，它在這情況只是一個名義上的領導者。在這個案例中真正的“壞人”事實上是被從 DirectShow 分開的 Windows Media Player SDK 因為它是對 DRM 有最多支持的地方。 在相同方面，DirectShow 也因對第三方媒體播放器功能的限制而受到指責，也就是説，在播放媒體文件方面，對Windows Media Player以外的媒體播放器存在不公。