DirectShow

DirectShow（有時縮寫如 DS 或 DShow），開發代號 Quartz，是一種由微軟公司開發的能夠讓軟體開發者對媒體檔案執行各種不同處理的應用程式設計介面。它是微軟公司對早先 Windows 影片科技的一次更新。基於微軟公司 Windows 元件物件模型（COM）框架，DirectShow 為大部份微軟公司程式設計語言提供了一個媒體的普遍介面，而且是一個可擴充套件的，能在使用者或開發者的命令下播放或記錄媒體檔案的，以 Filter 為基礎的框架。DirectShow 開發工具及憑證被加入到微軟公司 SDK 平臺的一部份。Windows Media Player 這樣的應用程式運用 DirectShow 或者它的各種衍生來播放來自檔案或是網際網路上的內容。DirectShow's 的最大的競爭對手是蘋果計算機的 QuickTime 框架。

歷史

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 Base Classes）” 的一組類別來處理大多數的工作。基本類的程式碼大小几乎是整個 MFC library 類大小的一半。所以即使有了基本類，DirectShow 的 COM 物件仍然是相當的多，仍然會讓開發者在開發時倍感辛苦。DirectShow 的 API 有時違反傳統的 COM 規則，比如在方法中引數的用法等。因此，開發者也時常使用比 DirectShow 更高層次的 API，如 Windows Media Player SDK，它提供了較少 COM 介面的 ActiveX 控制。

DirectShow 也因為僅支援非常有限的數位版權管理（DRM）功能而受到批評。相對的，Windows Media Player SDK 支援較多的 DRM 功能。