不好意思，小弟第一次發言

如有缺漏或是不足的地方，請多多指教

用DirectShow將CCD裝置畫面擷取到電腦顯示的方式有VideoWindow & SampleGrabber 兩種

目前我是用SampleGrabber裡面的OnBuffer Event來取代Timer作持續的抓圖

可是測試的時候遇到一個狀況

OnBuffer Event 啟動以後會不斷的吃記憶體而沒辦法釋放，請問這樣是正常的嗎？

目前我是在Filter , FilterGraph , SampleGrabber 加上了 FreeOnRelease

結果沒有變化





而使用Timer定時去GetBitmap並不會持續吃記憶體

請問有沒有方法使用 OnBuffer Event 來GetBitmap的狀況下釋放記憶體？

PS: 在 OnBuffer Evenet 以及 Timer 中用的都是 GetBitmap() 來取得影像至Img元件

編輯記錄

目前試的結果是這樣

如果一次只連結一個 Filter,FilterGraph,SampleGrabber
OnBuffer Event 的功能是正常的

但若是同時使用兩組以上的 Filter,FilterGraph,SampleGrabber
OnBuffer Event 會在切換的中間不斷的堆疊記憶體 (不知道這樣敘述是否有誤@@)
而造成無法正常釋放

可是看不懂 DSPack 的Pas語言 後面的嘗試不知道要如何下手
有人能提供一些其他找出問題的方向嗎，感謝萬分~

請問妳有SampleGrabber的範例程式給我參考嗎
擷取CCD的影像部分
謝謝
===================引 用 daldal 文 章===================
不好意思，小弟第一次發言
如有缺漏或是不足的地方，請多多指教
用DirectShow將CCD裝置畫面擷取到電腦顯示的方式有VideoWindow & SampleGrabber 兩種
目前我是用SampleGrabber裡面的OnBuffer Event來取代Timer作持續的抓圖
可是測試的時候遇到一個狀況
OnBuffer Event 啟動以後會不斷的吃記憶體而沒辦法釋放，請問這樣是正常的嗎？
目前我是在Filter , FilterGraph , SampleGrabber 加上了 FreeOnRelease
結果沒有變化


而使用Timer定時去GetBitmap並不會持續吃記憶體
請問有沒有方法使用 OnBuffer Event 來GetBitmap的狀況下釋放記憶體？
PS: 在 OnBuffer Evenet 以及 Timer 中用的都是 GetBitmap() 來取得影像至Img元件

抽空看了DSPACK的Source Code
裡面SampleGrabber的OnBuffer Event是利用Thread去抓取圖片
所以如果直接用顯示影像Timage->Picture->Bitmap去抓取的話
有一定機率(視你的CPU、WebCam處理而定)會造成Thread端無法釋放記憶體
因為此時你的Application正在Invalidate中

所以改成用Assign賦予圖片DIB到Timage->Picture->Bitmap，
速度會慢一些(因為此時TImage會等待Assign動作完畢)
然後Invalidate才會觸發重繪
但是至少記憶體就可以正常釋放了。

PS 以上說法也可能有錯，因為DSPACK Code有很多地方還是看不太懂@@

===================引 用 psp67101 文 章===================
請問妳有SampleGrabber的範例程式給我參考嗎
擷取CCD的影像部分
謝謝


在Dspack的/Sample/BCB目錄下有可以Compile的CCD影像擷取範例
記得要改Include路徑，就可以了

這幾天在閱讀 MSDN 上的 DirectShow reference

看到了ISampleGrabberCB::BufferCB Method 中有這麼一行
Note This method receives a pointer to the original sample data, not a copy.
The original documentation incorrectly stated that pBuffer contains a copy of the data.

然後加上ISampleGrabberCB::SampleCB Method 中的備註有提到
If the sample is a DirectDraw surface, the surface is locked during the callback. The Win16 lock (also called Win16Mutex) might be locked as well. Both of these locks create the potential for deadlock. If the callback thread waits for a thread that is trying to call a DirectDraw API, it can cause deadlock. In addition, if the Win16 lock is being held, deadlock can result if the callback holds a critical section or waits for another thread to complete any activity. Therefore, the callback should not perform any actions with the potential to block, such as holding a critical section or waiting on another thread. Also, do not call any GDI or USER32.DLL APIs that might cause a window to move. For more information about the Win16 lock, see Knowledge Base article Q125867, Understanding Win16Mutex.
所以答案就揭曉啦
因為Thread事件發生時，我把他搬移到Bitmap元件中
Bitmap寫入後會去呼叫 GDI 的 drawdib 去進行 paint 動作
而這些動作會導致記憶體釋放的時候
被鎖定住而無法動作
所以就一直堆啊堆啊.....T_T
以上