Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

在本系列文因為工作上的產品應用需求，進而探索到很多層面的點滴事。透過每篇 EP 的分享把這些點滴整理，看起來或許像是個獨立的小品抒發文、也或許是一系列技術研究文！？

總之，就當作的隨手雜記文吧！

本篇是 莫名其妙就跟世界等級的 OpenSource 專案攪和了!? 系列文的 EP16。

先不論 MinGW 版本與 MSVC 版本是否在執行上有效能差異等問題，透過上一回 EP15 比較的安裝後所佔的磁碟大小即可發現：

Gstreamer 同樣的版號(version: 1.26.5)的 MSVC 版本所佔的磁碟大小跟 MinGW 所佔的磁碟大小，比值為

316MB : 1659MB

約莫有 5 倍以上的差距。

對 IoT / Embedded 裝置來說，裝置上可用的儲存空間可是錙銖必較的；先假設兩種版本的效能一樣好了，能讓裝置的儲存空間多出額外的 1200MB+ 的使用，不香嗎？

光是這點就值得把 Gstreamer 從 MinGW 轉換到 MSVC 的版本。

雖然產品移植到 Avalonia UI 時所使用播放影片的功能，是沿用 gstreamer-netcore 的處理架構去建構的，而其運作則是必須基於使用 Gstreamer 的 MinGW 版本才能正常運作。

也如同 EP07 文末提到的：

撥放影片的上面疊加其他的畫面控制元件，處理出很出色並有趣的畫面互動效果。

這部分整合到產品的整體執行運作上也都沒問題。

但...

事情的發展往往都不會這麼簡單。

起因是移植到 Avalonia UI 的產品版本在 Windows 環境準備上線前，驗證團隊就有觀測到產品運作一段時間後，都會有莫名的微幅記憶體洩漏無法回收。

雖然在一定的程度上，這記憶體洩漏問題不影響產品進行正常服務與營運，但這對開發團隊來說卻 不樂見 看到產品有這樣的運作表現。

這個 不樂見 是出自於開發團隊對自己的一種 "要求" 吧！

只要是在開發團隊力能所及的範疇，能把產品運作調校的更好更穩定，那開發團隊就會往這個方向去努力邁進。

在查記憶體洩漏問題的過程中，不斷地對產品程式進行了相當多的試驗與調整。但無論如何調整，種種跡象都指向播放影片就是會發生記憶體無法回收的狀況。

只好把關注點轉移到 Gstreamer 跟 C# 要運用 Gstreamer 時，所需要使用的 binding 程式：gstreamer-sharp。

就如文章開頭的所寫的，轉換至 MSVC 版的 Gstreamer 會是第一優先的選擇。

而要轉換至 MSVC 版的 Gstreamer，就得先克服 gstreamer-netcore 被綁定在 MinGW 版本的 Gstreamer 上的問題。

PS 若對 "產品" 的開發過程有所謂的迭代概念去理解其發展時，也許就會理解到其發展往往不像 "專案" 性質的線性式發展。

因此在看待文章的敘述時，若能把這個迭代概念帶入的話，也許會比較好掌握其中的感覺。