唉...　我來解釋一下好了
在這邊先把 decoder 與 encoder 分開，這樣比較好說明


一．
先來說明 decoder 的部份 - 以koepi's XviD為例

在 Windows下若要播放 XviD 影片時，此時 Windows 的播放程式會去尋找、並呼叫 Xvid Decoder 以要求解碼
通常這時的 Decoder 會是由已安裝 koepi's XviD 放出來的 xvid.ax 所管轄
而這個 xvid.ax 則會去調用真正的 XviD 的核心，也就是 xvidcore.dll
你可以把它理解成 xvid.ax 只是 XviD 的 interface
而 xvidcore.dll 則是它名字的意思


當然，這是電腦內只安裝了單一 decoder 的狀況
假設在同個系統內加裝了 Divx 與 XviD decoder 時，
由於 FourCC support 讓 XviD decoder 也可播放 Divx 格式
解碼的優先順序這類旁支末節就暫且不提

可以想見的，兩個 decoder 在極端狀態下就會打架
各自的 interface 會為了同一格式的檔案搶著作解碼
這也是為什麼會有人提出安裝多個 codec 會不穩的原因之一

當然造成不穩的原因還不止這些，我在文後會稍作解釋


二．
再來談到這如 ffdshow 這類整合 cdoec pack
是由於上述狀況其實還蠻常發生的，尤其在 WIN98 那個年代
嚴重一點就只能砍掉重練
所以 milan_cutka 為了解決這類問題
開發了 ffdshow

這類整合 code pack 最主要的目的，不僅僅是為了節省各自安裝 codec 的時間與精力
更重要的是，這類 codec pack 將會有

"獨立且單一的介面去調用電腦內的 codec"

如 ffdshow 的 ffdshow VFW (Xvid 的 GUI VFW component 則是 xvidvfw.dll ，之前這個檔案只是 core suffix)
由於調用的方式與編排在程式編寫時就已納入考量，所以解決了不同 codec 打架的問題


像 MPlayer 也是基於同一個原理，將大部份 codec 包在一起
並由自己開發的播放器調用
與 MPlayer 方式完全相反的則是 gabest 開發的 Media player classic
蠻有趣的狀況是，這兩種極端類型的播放器都有一定的佔有率(順帶一提，我是用MPC)
也沒啥誰好誰不好的，看自己習慣而定


三．
最後來談談 encoder

其實 endoer 與 decoder 的狀況類似
只是由 "將影片 decompress 輸出至顯卡" 換成 "轉換影片格式" 而已
方式大同小異。所以也同樣會遇到 encoder 打架的問題

拿 TMPGEnc 做轉檔為例
一般獨立安裝 codec 的狀況，轉換不同格式的影片
將由 TMPGEnc 內部設定，決定調用 encoder 的優先順序
VirtualDubMod 我記得也是同樣可以設定

早期有些轉檔程式則沒有這個設定，將由程式自己去做判斷
所以才會發生轉檔失敗的狀況

---------------------------------------------------

至於 ffdshow 與 K-Lite 的差異
我想 DSNB2 已經講得很明白了
只是容納程度上的差異而已

只是有些人裝完 K-Lite 這類東西，又回去裝了獨立的 decoder
或是裝了獨立的 decoder ， 在K-Lite再加裝一樣的東西上去
造成 encoder 與 decoder 兩邊支援度不一
原本被統一的狀況又變得混亂，因此系統不穩定是一定會的
而且會這麼做的人還真的很多....


另外
如同 MPlayer 的方式，將大部份 codec 包在程式裡
由自帶的程式調用 codec 的程式

目前我只知道 WinMEnc ，其他的就請自行摸索吧


憑印象打了好長一篇...
不知道這樣你是否能理解了呢？