跳至內容

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功能[來源請求]。

參看

[編輯]

外部連結

[編輯]
取自「https://zh.wikipedia.org/w/index.php?title=DirectShow&oldid=63108231」