這次報告的是GStreamer這個多媒體框架
可是很遺憾 我找不到任何的架構圖可貼
所以貼一張GStreamer Editor好了
這張圖裡多少可以看出一些GStreamer的概念
最外層是一個pipeline對應一個data flow
裡面出現的thread...目前我還沒看到任何相關的說明
暫時把他當成Bin來看吧
每一個element(包括pipeline, thread, bin)的左下角都有一組NRPP
表示這個element的狀態，分別是Null, Ready, Paused, Playing
Null : 沒占據資源
Ready : 拿了資源可是沒開始讀資料, 指標還在0的位置
Paused : 跟Playing一樣，只是clock沒在跑
Playing : 讀取/處理資料流
可是更遺憾的是 這個GUI已經快5年沒有更新了
現在的core是0.10版 可是GUI還停在0.08版
因為版本不對所以不給我裝
目前釋出的版本只有linux跟OpenBSD 4.1版
至於windows...Unfortunately, we are unable to provide up-to-date Windows binaries of GStreamer, due to limited developer resources.
官方說他們的API支援多種語言，可是目前的支援...
| language | status |
|---|---|
| Python | |
| Perl | |
| .NET | |
| C++ | |
| Guile | |
| Java | |
| Ruby |
--
這次講的部分主要是application的介紹
基本上就和SLIM差不多的概念
甚至簡單的MP3撥放可以利用他們的工具gst-launch command-line tool
$ gst-launch-0.10 filesrc location="test.mp3" ! decodebin ! Alsasink
這樣指定source, decoder, sink就可以撥放MP3
這三個element之間的連接和資料流的處理 都會自動完成
由於這句話...
GStreamer can bridge to other multimedia frameworks in order to reuse existing components (e.g. codecs) and use platform input/output mechanisms:
- Linux/Unix: OpenMAX-IL (via gst-openmax)
- Windows: DirectShow
- MaxOS X: QuickTime
接下來要看看plugins是如何實作
以及gst-openmax是如何利用plugins的機制來橋接OpenMAX-IL
--
這次的問題(我記得的部份啦 有忽略的請再問我一次)
※pad的方向定義
以element之間的資料流動來看，資料從前一個element的src pad流到下一個element的sink pad，所以以一個element的內部而言，左邊是sink pad代表資料流入，右邊是src pad表示資料流出
※每個pipeline只對應一個thread?
基於這句話 Multi-threaded pipelines are trivial and transparent to construct 還有Manual的前半部只有提到每個pipeline會以一個新的thread來執行，我認為是的
※一個pad可連多個pad?
關於pad的描述雖然沒有明確定義，但Manual中的一個Tee element的例子說到它的輸出(src pad)會因為需要複製一個資料流輸出，而增加一個pad(on request)，相同的輸出都需要兩個src pad，所以我想GStreamer裡pad的連接應該是1對1的
※以ogg decoder而言，解出的視訊與音訊是否能同步
現在想想，Manual中提到application與pipelines之間的溝通是非同步的，但音訊跟視訊在同一個pipeline中(同一thread中)，是否能同步，我還要查查看
※負責暫存資料的buffer是只有source element有在maintain嗎
Buffer can be allocated at any time during the execution, when ever needed.
※假使有多個pipelines存在, 每一個是一個單獨的thread嗎?
這方面我也越來越有疑問了@@，我還要再找找看文件才敢回答...
--
090310
這禮拜我要報的是GStreamer怎麼跟OpenMAX IL結合
根據官網所提供的資料
目前OpenMAX IL層 只有一個open source的實作叫做Bellagio project
最新版提供18個components可用
GStreamer也針對它 提供一個gst-openmax的plugin來做結合
原理上是gst-openmax對Bellagio project提供的每一個component
做出一個對應的element 在這些elements裡用的是OpenMAX IL的API
利用呼叫OpenMAX IL API的方式來與OpenMAX IL溝通
官網提供的文件中提到GST跟OMX的比較
以及如何利用OpenMAX IL API來傳輸資料
但都是講概念 實作方面得自己去trace code
不過在Bellagio project官網上關於GStreamer plugins有一段話
The development of Gstreamer plugins that use OpenMAX components is maintained at GstOpenMAX on freedesktop
A set of old plugins developed in the context of Bellagio project can be found here
This part of the project has been discontinued, and no support will be given for it.
25 則留言:
喔，可以問個笨問題嗎？這是要 survey 跟 SLIM 類似的 component-based platform 嗎？還是為了研究某些 programming model ?
阿...我現在的目標是看GStreamer怎麼跟OpenMAX接在一起，如果可以的話，就用同樣的方式讓SLIM跟OpenMAX銜接，目的好像還是讓他們跑在CUDA上面。
ㄚ凡自己講了, 不是好像.
我一直在想SLIM要繼續下去嗎? 假如有G可以用, 不過基於訓練學生的理由, 假如每一屆負責CBSD的同學可以從了解到開發新工具都可以自己來, 對於功力的幫助顯然會大於只用G, 否則我相信到後來就只是會用而不會開發了.
另外是既然OpenMax, OpenGL,OpenCL都可以用GPU, 那麼假如我們做Multimedia的沒能用就有點可惜, 不過我實在是不想自己再來開發所有的codec了, 假如塞公學會在OpenMax, OpenCL下implement我們自己的演算法, 那麼這些codec都可以為我們所用, 外加上自己做的, 會是很好的開發與成果展示環境. 再加上SLIM後, 會更好用.
過去 SLIM缺少諸多的基本原見的問題也獲得改善.
不知您意下如何呢?
喔! 好久不見了.
Once more question.
假使有多個pipelines存在, 每一個是一個單獨的thread嗎?
嗯嗯，"捨棄 SLIM 改用 GStreamer"跟"基於訓練學生的理由"的確是有矛盾的，不過我想還是要 survey 一下 gstreamer 的成熟度，才能知道使用 gstreamer 是不是只是寫 plugin 這麼簡單，我看了學弟的投影片和介紹感覺 gstreamer 離完成還有一段距離。所以開始使用上一定會遇到許多問題，甚至需要進去修改/trace gstreamer 的 code，可能會花了許多時間與功夫，但還是未能對gstreamer 這類 CBSD 的架構、實作有所瞭解、體悟！
我私心還是希望 SLIM 能維持下來 XD
不過當然要考慮一下維護、改進 SLIM 的功夫會比 gstreamer 多！此外，考慮到 GPU 的使用，可以參考一下 gstreamer 是怎麼去整合 OpenMax, OpenGL,OpenCL 這些東西，如果他們的整合只是呼叫 library ，那或許移植到SLIM 可能也會很快速，這邊就要請ㄚ凡哥 survey 一下了，你可以把你的發現、問題 post 到lab blog 上，mobo、禹鴻和我都很樂意給些意見的，他們會給你真知灼見，我則是喜歡誤人子弟 Orz
那就先謝謝學長囉
其實GStreamer的官網上不斷提到"There is still a number of items on our TODO list."這樣的話
而且發展了快7年還在0.10版
相信裡面有不少地方不符我們的需求
如果時間許可 能一步步把SLIM改進當然是最好的了
畢竟是lab自己做的 也有原始碼可看
至於GStreamer怎麼跟OpenMAX整和我還要一點時間來看
我覺得SLIM是個不錯的學習平台，概念簡單也有一定的效率，是不是需要把SLIM發展到強大如商業產品?我想是不必要的，或是說可以順其自然的。介面白痴如我，當時也很enjoy在寫SLIM使用的一些小的component，組合起來跑很有樂趣。
就像老師常常在說的，everything has a purpose。我來提一下SLIM的演化，讓學弟想想GStreamer可不可以幫我們改進SLIM，因為當初不學GStreamer是有個理由的：
第一代：SMP(Scream Multimedia Platform?)
整合實驗室各方面研究的成果。比如說，你目前在做一個video decoder的演算法，如果你把你的演算法包成一個SMP的filter，輸入與輸出符合某種格式。你就可以不用實作video display與檔案輸入或更複雜的demux動作。直接利用SMP的環境很方便地就能秀出成果。除此之外程式執行過程中還能“動態”調整參數，並且以GUI呈現的功能(小路學長設計的Scream Script)，就變得符合audio processing的需求，如葉家伶(Y+0)學姐的論文成果、某學期電腦音樂的作業、IPTV的demo…。
這個時期的references有：
a. MS DirectShow
b. Max/MSP (http://www.cycling74.com/products/max5)
c. Matlab/Simulink (http://www.mathworks.com/)
c. CLAM (http://clam-project.org/)
第二代：SLIM(Scream LInux Middleware)
SLIM的發展目的是希望能在embedded system 上面有像上一代SMP那麼好用的filters，與GUI。自然而然的，選擇了Linux作為環境。值得注意的是，當初選擇multithread方式，先採用了pth，後來才改成與SMP行為類似的pthread。會想使用pth的原因是受到JACK(a)執行模式的影響，它要求一連串的filters，逐一在一定時間內完成，不是用multithread的方式完成。pth在這個地方剛剛好。一來我們能採用固有的SMP kernel scheduling的方式，即每一個filter一個thread；二來其non-preemptive方式，能確保每一個filter確定完成一段code之後，然後主動讓下一個filter執行的權力，達到近似JACK逐一執行filters的效果。至於GUI的部份，禹鴻整合了minigui，作為在embedded環境中UI的呈現。在Linux之下，自然而然會找Gstreamer作為參考，不過我們的考量是filter從SMP搬到SLIM，儘量動到最少的code，因此就和它無綠了。
這個時期的references有：
d. JACK (http://jackaudio.org/)
e. GNU Pth (http://www.gnu.org/software/pth/)
f. GStreamer (http://www.gstreamer.net/)
第三代：(就交給學弟們囉！)
學弟們現在應該是碰到一個好玩的時候，要怎麼讓SLIM支援multicore。首先是看看大家怎麼做的：
GStreamer + OpenMAX + (DSP)
OpenCORE + OpenMAX + (DSP?)
這些作法都有它的目的與用途，是不是都已經清楚了呢？然後才看我們要怎麼和SLIM接。
希望對大家有幫助，
還有中間歷史有錯也麻煩更正><
Excellent!
這篇講的好唷， mobo 太強了，講的很清楚也很棒！我看的都想畫張祖譜、分支圖了！
補充一點， SLIM 在禹鴻、mobo 快畢業時，由當時的專題生振亹試著往 realtime 和整合其他語言（e.g. Java）發展。另外，SLIM 與 SMP 還有一個很大的差異：將 event 分成 sync/async, data/cmd 試著去產生更多的應用！
PS. 為什麼我們當初會從 pth 又回到 pthread ？
我這幾天忙雜事, 尤其是寫文章, 一篇是罵人的, 一篇是感恩的. 說到罵人, 我是慚愧的.
假如我的回憶沒錯, pth與pthread是因為兩件事, 一個是希望跨Windows與Linux, 一件是GPL與LGPL的問題.
我的工作是向前看以及向別人看齊, 但是沒有同學幫忙, 我是一件事也做不了, 除了感謝之外, 還是感謝.
感謝維城學長的鼓勵, 您知道我一向看事情事都會希望有一天可以變成商品的, 不過我還是希望以教學研究目地為優先考量, SLIM會慢慢轉向適合Multi-core也是有時代與應用考量的, 目前aaa與bbb在規畫的東西也是SLIM的變形, 至於SLIM與新東西會怎麼走下去, 要看大家的努力, 請拭目以待.
很高興你當時還算enjoy這種寫法.
mobo把歷史交代得不錯, 尤其是演進忠我們參考了哪些東西. 我還是要補聰一些枝枝節節.
SLIM事實上有Windows版, 本來交給showmin來測試並且希望可以件件發現SWIM (Windows版SLIM), 但是事過境遷, 也不知道要找哪位繼續來做, 我不知道SWIM是否還有其需要, 請mobo與Keiko發表一下意見.
其次是keiko做的跨平台的lib. 這點很重要, 我想請keiko來說一下.
最後當然是學弟做的real-time以及整合其他語言的, 由於新版的Linux支援soft real time, 當年的努力以現在看來, 價值就是訓練學生, 整合其他語言所得到的知識, 看來會在OpenESL裡有用.
最後還是一提, SLIM未來可能的方向: 一個是往support multicore運算, 而隨著不同的multicore架構而會有不同的底層實做, 另外是跟OpenMax整合, 以利用別人開發好的codec資源, 另外就是開發元件, 讓以往無法在single core 跑起來的演算法可以運作. 至於其他, 我請大家補充.
我再說兩件事.
當年SMP確實幫了大忙, 尤其是IPTV那次demo, 要不是SMP, 那真不知道要怎麼過電信總局那關.
至於下一代, 我們考量的除了DSP之外, 還有如cell與GPU一樣的Multicore, 所以才想引進OpenMax. 自己要來弄一堆codec真是要命, 原諒老師偷懶一下, 我老了.
我印象中後來不用PTH的原因是因為它將很多機制寫死，雖然較好用但彈性較小，這樣的限制是無法滿足唯中這一群人的胃口的。
Windows 版的 SLIM (SWIM) 我來交代一下，最早開始將 SLIM porting 到 Windows 平台是在修嵌入式軟體課程，我跟kiwi一起將 SLIM 搬到 WinCE 上，water 後來有利用這程式進行進一步的開發及修改。kiwi畢業後，冠廷則將這支程式改回在 WinXP 上，不過這版本就沒聽說有誰拿去用了。
2006年 CCRMA 的 Nando 受邀來解說 PlanetCCRMA 跟 Jack 時，我就希望理想中的 SLIM 能像這樣，再加上唯中的 Scream Lib 就能向指揮家系統 (跨平台&同步) 更進一步啦。
SWIM：
SWIM 是 showmin & kiwi 趕了幾個晚上改完的，我是那一切的目擊者，目前還不是利用 SCREAM Lib 改的就是！而 SCREAM Lib 目前也不是只能不太完整的支援 WinPPC 5。新的 WinPPC 和 WinCE 版本還需要測試。
SLIM on Windows：
已經利用 SCREAM Lib 改了一個雛型出來，在 181 的 svn 可以 checkout slim2 這個 project 。不過我只有改過一、兩個簡單的 filter 來測試 engine 而已，相信還有一些 bug 沒被發現！
SLIM & realtime：
目前是倚賴底層 Linux kernel patch 成 realtime OS ，然後靠 filter 就是 thread 的特性去被動排程，期望可以達到 real time。但根據之前整理過的一些 realtime/realtime OS issues，這樣很難說服使用者，這就是一個支援 realtime 的 middleware。當時也很難抽出人力去做更深入的研究。
SLIM 和 SMP 差異：
SLIM 是 event push 而 SMP 是 pull。
Why SLIM：
補充一點，當時在 SMP 似乎有遇到一些 timing 的問題(?!)，而在 Windows 上要做許多功夫才能克復，所以有了以 SMP 為背景再做一個新的 middleware 的想法。
對了，下面的話，好刺耳 ><
為什麼這句話是“這樣的限制是無法滿足唯中這一群人的胃口的。"
而不是“這樣的限制是無法滿足景翔這一群人的胃口的。"
或是
“這樣的限制是無法滿足禹鴻這一群人的胃口的。"
因為starry是不嘴炮的乖小孩，而mobo有很多個胃，會模糊焦點。
This is about the most 爆笑 的理由 i have ever heard in these days.
My question is : do we need to continue our effort to have a windows version?
Your opinions are welcome.
As for OpenMax, Please go to 塞公的OpenMax那串.
回應老師的問題：do we need to continue our effort to have a windows version?
我自己認為以功能來說，沒有很確切、急迫的需求，讓我們必須提供 Windows 版本。但有三項因素可以參考：
1. Windows 的使用者多，對於要推廣實驗室的東西，這是個不錯的出發點。
2. Windows 的開發環境比較友善。
3. 或許，哪一天 Windows 會派上用場。
但以超過半數的使用者的角度來說：
1. 有 Windows 版很好，跟我的習慣很接近。
2. 耶，SCREAM Lab 想參考或是做進來 的 GPGPU framework 都可以跨平台，為什麼 SLIM 不行啊？
以"前 SLIM 和 ScreamLib助拳人"的角度：
1. C/C++ 沒辦法 write once, run anywhere。不過要做到 write once, compile anywhere 倒是可以的。無論是自己寫一個 library 或是用一些現成的 library （e.g. boost, qt ...） 都是很好的訓練。
但以現實面來說，開發和維護多平台的 SLIM 會給實驗室帶來一些問題：
1. 複雜：使用一些跨平台的函式庫會有一些方便，但是當函式庫不 work 時，可能就是痛苦的開始！若是用 ScreamLib ，可能會遇到 bug ，開發時搞不清楚是誰的問題。
2. 跨平台需要花費額外心力在問題以外的地方，舉例來說：像是今天想做個 thread library ，你會發現 Windows 跟 POSIX 介面不一樣，然後提供的 synchronization mechanism 也不盡相同，你必須花費而外的時間去抽象化這些概念，然後把他們實做出來，過程中會出現一堆 bug …
3. test：現在的 SLIM 和 ScreamLib 都沒有完整的 test，哪怕只是加了一個新 feature/解了一個 bug，都可能在實做的平台或是另外一個平台上產生問題。
零零落落寫了一堆，很雜亂又沒有直接回答問題，但我只能說，多維護一個平台很累、很辛苦，尤其是當實驗室的大家都偏向某一個台平開發時，開發另外一個平台會格外辛苦，因為你少了很多 user feedback/test 來幫忙 verify 你的程式！
ㄜ，但儘管如此，要是今天我還在實驗室，我一定還是會來一下 SLIM on Windows 的！
推樓上，像 CCRMA 的 Nando 這樣，錢拿少少的可是有校方資源然後做出一個真正完整的東西，而且這期間一定有很多user在回報bug以讓這project趨於完整。
我覺得關鍵的點是：動機。
最近塞公跟阿凡所搜尋的主題是否有必要在 Windows 上？或者，什麼樣的動機是需要 Windows 版的 SLIM？唯中已有提出幾點。
對我來說，最吸引我的動機，是想要用一個平台包下 MacOS、Linux、Windows，平台上除了要有很多與多媒體或電腦音樂相關的元件可以使用外，人機介面也很重要，像義崧做的二胡手寫板，或者過去趙菁文老師曾提過的指揮家。這平台既可以用來當media player，也可用來當 analyzer/synthesizer，更可以拿來當小孩子的玩具。以「讓想做研究或想寫人機介面的人都愛用這平台」為目標，這野心是不是太大了？XD
現實是，這東西不能讓我畢業，也不能付錢給唯中。。。
keiko:
你真會打太極. 又說一些不可能的話. 我要是越心十萬雇你, 你會回來改嗎? 哈哈!
看到showmin的發言, 我一剛開始很感動, 不過最後一段|||. 唉呀! 要畢業的才要做, 現時的悲哀!不過今天我撥Chuck給大學部學生看, 我知道我觸動了一些人了. 這讓我想起當初的JavaOL, 要是我們"動機"強一點, 也許On-the-Fly JavaOL就成功了.
我們現在還是先把新版本SLIM做好再說, 原則上, 塞公會負責底端DL與非DL的codec的使用方法, 以及如何自建lib 不管此一lib友沒用到multicore.
ㄚ凡先在Eclipse把發展環境架起來. 這同時會考慮cell那邊要不要一起做. 這要請aaa與bbb來講, 原則上, GEF部分可以一樣.
至於Screamlib, 一但前面完成,我會請同學開始找時間試用, 看問題在哪裡?
keiko, 這一次改版是否就用Screamlib了呢?
對了, 我今天的系務會議裡提議, open source的下載率為該領域全世界前20名者, 算一篇A級期刊或會議, 也就是再加一篇小期刊論文就可以畢業了.
你找一下像Open Webmail的排名吧!
突然多了這麼多回應...
昨天聽完ㄚ凡的報告, GStreamer/SLIM/OpenMAX IL都是類似的東西, 既然GStream可以包OpenMAX
就有個突發奇想, SLIM可不可以包GStreamer&OpenMAX?
整合方式=多包一層+API轉換 Orz
過去我曾做過類似的事情，就是在soc designer上包進 SMP (特化過的) 跟 Windows SDK，之後玉琳論文的demo還加上matlab。我們確實可以以一時的目的來做這件事，只是如果沒有長遠的規畫的話，一旦這東西沒人用 or 開發者離開了，這些東西也會一併被遺忘在一旁。
所以我很支持並期待學弟們能傳承 SLIM，無論大家為了什麼目的而特化出新版的 SLIM，SLIM的精神便可一直存在。
aaa的話不無道理, 這是一種方便. 讓我們用既成的GStreamer做好的東西, 又可以連接自己利用OpenMax以及其他工具平台做出來的元件. 不過, 這樣的話, 多了一層, 有包Gstreamer的元件效率會變差的. 但是泛用性會變好.
不知道會不會有 OpenMax 版本更新了，可是 GStreamer 無法對上的狀況發生？
ㄟ! 會的, centcent. It Happens all the time.
ㄚ凡, 可以提一個Schedule來說你接下來的工作了嗎?
看一下Chuck, 也給自己一個期許吧!
張貼留言