關於opencv開啟攝像頭成灰色問題的原因
問題描述:
capture可以開啟,但是無法抓取frame。
原因:
查詢資料看到,可能是因為驅動的原因導致。windows 下的攝像頭的都用了Directshow,而opencv 的這兩個函式都需要使用VFW的驅動才能正常使用。
解決方法:
使用videocapture或DS
----------------------------------------------------------------------------------------
關於VFW和DS
----------------------------------
VFW是Windows 3.x的技術,面向Windows 95或者之後版本Windows的程式應該用其後續者DirectShow。面向Windows Vista之後版本Windows的程式應該用Windows media Foundation。
VFW(Video For Windows)是從Win95就開始使用的一組對音視訊操作的一組API。 DirectShow是DirectX6.0之後發展起來的對音視訊操作的COM元件SDK, 相對於DirectX是獨立的。當時叫DirectX Media SDK。 在DirectX8.0之後就整合在同一SDK中,就改稱現在的DirectShow. Media Player就是基於DirectShow技術之上的。根據使用驅動程式來分類,視訊卡可以分為VFW和WDM。 VFW卡實現的功能簡單,比起VFW,WDM還支援一些新的特性:電視接收、1394介面的裝置、桌面攝像機、多條視訊流同時輸出等。DIRECTSHOW為了相容VFW卡,使用了一個標識為CLSID_VfwCapture的Filter來支援VFW卡
http://blog.csdn.net/hardvb/article/details/768246 本文提供了使用directshow代替opencv的vfw 的原始碼,與轉化為iplimage格式的演算法. 實驗中發現opencv的cvCaptureFromCAM 使用的是vfw,採用訊息機制,速度較慢,測試發現fps只有 9-12左右,太慢了. 發現經過使用directshow後速度提升到60幀/s.在opencv group上了解到這是一個普遍問題,也許有人做過轉換,卻沒有完整的例子與程式碼.在此貼出.對希望提高opencv視訊分析速度的有所幫助.
win7 OpenCV 問題描述:歷史問題以前Windows的攝像頭和視訊播放介面叫VFW,又老又醜,改成DirectShow了(剛出來的時候叫Active Movie)。據說Windows 7 又改成了Media Foundation,沒完了。如果是無驅的,Windows只提供了DirectShow通用驅動,因此通過VFW方式無法訪問。而如果是有驅動的,那麼一般來說VFW和DS是可行的。另外,因為歷史原因,DirectShow相容傳統的VFW,而VFW則不可能支援DirectShow,所以你的攝像頭即使只支援VFW,也可以用DirectShow採集,因此不存在什麼DirectShow不支援的攝像頭。如果你的攝像頭是無驅的,沒辦法,換一個有驅的。下面說說問題的另一頭:OpenCV,OpenCV 1.0的HighGUI只提供了VFW介面的攝像頭支援( Windows上,Linux上則多許多),為此他還提供了一個叫cvcam的獨立函式庫,文件裡有的。OpenCV 計劃用HighGUI支援DirectShow,以便淘汰cvcam庫。期間,出現了一個叫Video Input的開源庫,通過簡單的C函式訪問DS攝像機,並且和OpenCV配合良好,以至於OpenCV的官網上有他的介紹。最終OpenCV 2.0納入了VideoInput,從而讓HighGUI支援了DS,但是O penCV 2.0的用法真的是…… 所以還有三個選擇: cvcam VideoInput OpenCV 2.0 另外,OpenCV 1.0讀取和儲存AVI的介面也僅僅支援VFW,視訊編解碼也有VFW和DS的區分,只支援VFW的,因此行為可能和Media Player等不同,因為目前大多數的播放器使用DS。 2.0開始用內建的FFMpeg了,支援格式較為廣泛,我曾經順利地開啟rmvb和mkv,也算是一種進步。BTW,FFDShow就是DS包裝下的FFMpeg。
http://blog.csdn.net/heiyang/article/details/6715424說起視訊捕捉問題,先來看一下視訊捕捉卡。根據使用的驅動程式的不同來分類,目前市場上大致有兩種捕捉卡:VFW (Video for Windows)卡和WDM (Windows Driver Model)卡。前者是一種趨於廢棄的驅動模型,而後者是前者的替代模型;WDM還支援更多新的特性,比如直接支援電視接收、視訊會議、1394介面的設 備、桌面攝像機、多條視訊流(Line-21或Closed-Caption等)同時輸出等等。採用VFW的一般都是些以前生產的卡;
市面上新出現的,一 般都是採用了WDM驅動程式。另外,視訊捕捉卡的介面,可以是以PCI或AGP的方式插入PC機箱,也可以直接以USB介面的方式外掛;還有就是通過 1394介面與PC機相連的數碼攝像機等等。
基於VFW的視訊捕卡 VFW技術受到的很多批評,因它捕獲的資料儲存到磁碟上會佔用大量磁碟空間,每秒資料量超過20M,(有人試驗640*480視窗1s大約需要10M), 同時需要大量的客戶端支撐軟體,VFW體系架構上的不足在視訊會議應用上和PC/TV應用上被暴露無遺,這樣就要求一種新的視訊捕獲技術來彌補這些不足。 VFW的體系結構缺乏為視訊會議,電視瀏覽,視訊區域捕獲和VBI(Vertical Blanking Interval)資料流提供強而有效的支援。一些視訊卡等裝置開發商在設計自己的產品時,針對這些缺陷,對VFW進行了功能擴充套件。由於沒有統一的標準, 我們的應用程式在使用這些擴充的功能時,就必須要寫一些基於特定硬體的程式碼。這就意味著當要改變捕獲驅動程式時,就必須要對顯示卡的驅動程式進行修改。
基於WDM的視訊捕獲 WDM視訊捕獲設計就是為了來解決VFW體系結構中存在的這些問題。WDM視訊捕獲主要的好處體現在:
l 可以為裝置(如基於USB,IEEE 1394通訊方式的攝像頭 )提供32位的驅動程式。l 允許DirectShow 和 WDM流協同工作。
l 可以在視訊捕獲裝置和DVD/MPEG裝置間,為硬體(如video ports和 chip sets)共享一個分類的驅動程式結構(Stream.sys)。
l 支援多個數據流。
l 允許電視訊號調頻和輸入選擇。
l 支援視訊區域捕獲,區域顯示和VBI。
l 允許使用DirectDraw® VPE (Video Port Extensions)管理視訊輸入。
在一個單獨裝置上可能會有多個元件共存的情況,這些元件包括DVD解碼器,MPEG解碼器,視訊解碼器,調諧器,音訊解碼器。WDM資料流就是用於解決這種情況而建立的。它是個統一的驅動模型,可以支援所有的這些裝置和去處理它們的資源分配。WDM資料流為標準資料型別和使用者自定義資料型別提供了統一的資料模型,同樣,它定義了大部分的標準裝置的屬性,並且根據需要可以很容易地實現擴充。因為按WDM資料流的協議,它支援在裝置核心間進行資料傳輸,而不需要在使用者模式下進行資料轉換。這樣可以獲得較高的效率,減少不必要的工作。作業系統仍然支援VfW驅動程式,但是依賴於VFW的開發將逐漸減少,這是因為下面三個原因:
l WDM資料流為基於電視瀏覽和視訊會議的捕獲裝置提供了優化支援。
l DirectShow提供了更強的功能。
l Microsoft 將不會對VFW進行持續開發。
上面這段話節選之http://blog.csdn.net/suntaoznz/article/details/596180。http://blog.csdn.net/suntaoznz這個部落格中有幾篇文章介紹了VFW和WDM。
http://wenku.baidu.com/view/07af18d380eb6294dd886cb8.html比較詳細的介紹了WDM視訊捕獲。
一.VFW
VFW(Video for Windows)是微軟公司1992年推出的關於數字視訊的一個軟體包,它能使應用程式通過數字化裝置從傳統的模擬視訊源得到數字化的視訊剪輯。簡單說,它就是從Win95就開始使用的一組對音視訊操作的一組API。VFW的一個關鍵思想是播放時不需要專用硬體,為了解決數字視訊資料量大的問題,需要對資料進行壓縮。它引進了一種叫AVI的檔案標準,該標準未規定如何對視訊進行捕獲、壓縮及播放,僅規定視訊和音訊該如何儲存在硬碟上,以及在AVI檔案中交替儲存視訊幀和與之相匹配的音訊資料。VFW給程式設計師提供.VBX和AVICap視窗類的高階程式設計工具,使程式設計師能通過傳送訊息或設定屬性來捕獲、播放和編輯視訊剪輯。在Windows 9x系統中,當用戶在 安裝VFW時,安裝程式會自動地安裝配置視訊所需要的元件,如裝置驅動程式、視訊壓縮程式等。 具體的開發步驟參考: http://blog.ednchina.com/opencv2008/193859/message.aspx。自己也順便轉載了一下的。
二.DirectShow
DirectShow是微軟公司在ActiveMovie和Video for Windows的基礎上推出的新一代基於COM(Component Object Model)的流媒體處理的開發包,與DirectX開發包一起釋出。DirectShow使用一種叫Filter Graph的模型來管理整個資料流的處理過程,運用DirectShow,我們可以很方便地從支援WDM驅動模型的採集卡上捕獲資料,並且進行相應的後期處理乃至儲存到檔案中。這樣使在多媒體資料庫管理系統(MDBMS)中多媒體資料的存取變得更加方便。它廣泛地支援各種媒體格式,包括Asf、Mpeg、Avi、Dv、Mp3、Wave等,為多媒體流的捕捉和回放提供了強有力的支援。
http://hi.baidu.com/��/blog/item/951b33348e684b3e5ab5f54e.html中詳細介紹了DirectShow捕捉如何程式設計。下面這段摘自維基百科http://zh.wikipedia.org/wiki/DirectShow 的話說明了 DirectShow的缺點。
播放一個檔案是一項相對簡單的任務,不過對於像是從視訊視窗接收特定視窗資訊到建立特定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以外的媒體播放器存在不公。
《深入淺出DirectShow Filter》http://caodixy.blog.163.com/blog/static/5094048820106133850563/?fromdm&fromSearch&isFromSearchEngine=yes