其實我原本不是要詢問的；所以也沒有期望能得到回應，沒想到卻引來有趣的回答（我喜歡這種互相討論的感覺）

>需要高速硬碟機這個應該是「極限吞吐量」的那個門檻
>也就是說當 CPU 同時控制 DMA 與處理捕捉程序時
>若達到頂點 (100%), 這時 DMA 是優先處理的, 之後才是影像捕捉程序
>然後捕捉軟體就會發現影像比預計的格數要少 .... 定義為掉格

但是因為計算DMA的記憶體位址對現在的電腦來說應該是輕而易舉的事，並不需要花費多少時間，計算完馬上就可以交回Processor的控制權，而影像擷取的資料都有Buffer在記憶體中，所以只是因為稍微延遲一點點並不會導致掉格，所以以上情況發生機率應該極小
所以要不是因為壓縮的Codec來不及，很少會造成掉格的（應該是啦）

>在實際應用上來說
>影像掉格時若掉的是同一區段
>那影像就完全 freeze 住了
>這點我在 mjpeg 時有欲到過

看不懂。

>一般以目前的 DMA/33 來說
>足夠任何影像寫入需求
>很不容易有 33MB/s 的影像要寫入吧?

我指的不是傳輸速度介面的問題，硬碟的實際寫入速度一定都比傳輸介面慢，所以我上面舉的例子其實是我自己做簡單的Banchmark後的結果
不過其實我的想法與你相同——現在的IDE硬碟的速度已經足以擔任一般錄影的工作了

>還有就是軟體快取這方面的問題
>matrox 有一篇如何最佳化非線性影像處理的文章
>裡頭有提到關閉軟體 cache

>原理是若有軟體 cache
>一開始寫入時, 硬碟資料並未寫入, 而是寫到實體記憶體中
>等到實體記憶體滿了, 軟體 cache 控制會將實體記憶體資料搬到硬碟
>這些步驟全部是 cpu 運作
>如此一來 cpu 基礎使用率就比關掉軟體 cache 要來的高

同樣的情況VirtualDub的作者也提到過，作業系統內建的Cache功能不適用於錄影
所以VirtualDub錄影的時候完全不使用作業系統的Cache，而使用錄影軟體內建的的Buffer對Codec壓縮後的資料寫入硬碟的數量作最佳化
這也是我說改善錄影軟體比換硬碟的效果更好的原因
還有，如果錄影軟體沒有內建Buffer的話，使用作業系統的cache仍然是必要的，否則掉格機率可能會更高，因為硬碟在寫入資料的過程的關係……應該沒人有興趣吧？有興趣的人自己去找計算機結構的書，或者再發問吧

附帶一提，給使用VirtualDub而不知道有這功能的人：
在Capture Mode時，選Capture->Disk IO
Chunk Size設為比你硬碟內建快取記憶體少，但是不要太小的數值（例如512K或1MB）
Chunk數量則看你記憶體多寡調整，記憶體多而且要進行高位元率錄影的話可以調大一些避免掉格（我是設32，但通常不用這麼大，設了也沒用）
底下的「Disable Windows write buffering」一定要勾