跳至內容

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」