--------------------- 2009/02/25 ---------------------
投影片連結
這禮拜是先介紹一下 OpenMAX
沒有實作過,所以整個架構上還沒有說很清楚
目前是打算把 DL 後面幾個feature看完
再來看一下應該怎麼去實作
OpenMAX AL 與 OpenMAX IL 的差別?
AL : OpenMAX AL is meant for media application developers.
主要是被用來開發應用程式的
在論壇中有提到說 目前 AL 1.0版 目前還沒正式發布
所以還沒有implementation 存在 有提到說大概在今年夏天就會公布 XD
IL : to integrate and communicate with multimedia codecs implemented in hardware or software.
代表是整合下層的codecs 像是把下層codecs包起來
而被包起來的名稱在 AL 這一層被稱做為object
--------------------- 2009/03/02 ---------------------
這禮拜是繼續將上禮拜沒看完的文件看完 至於會不會用到想說留到看完再來討論。
基本上OpenMAX IL 這一層主要重點是在於各個components之間的關係與溝通,而component內容可以寫到跟硬體或底層的軟體作溝通(像是可以呼叫alsa函式庫去播音樂,或者要遵循OpenMAX DL的規範 像 arm 有提供ARM OpenMAX DL Libraries有幾個codecs的API function可以使用(ex. mp3, h264...))就看自己要怎麼寫,因為跟寫slim component沒差多少。
另外有去看一個open source 的東西叫做 "Bellagio",是一個OpenMAX IL sample implementation for Linux,它上面有不多也不少的components在上面(10~30)個吧,我只有十個,看別人文章有三十個Orz,因為我一直安裝不起來,還沒辦法放一首mp3來聽聽。這個東西比較適合在學習寫IL的components的入門範例程式。有提供簡單的applications讓你連接各個components去做測試。網址 http://omxil.sourceforge.net/
還有,就是也稍微去找了一下nvidia cuda上有沒有跟 OpenMAX上相關的東西,發現是..只有新聞文章。其它就沒有了,可能還得再找找。
--------------------- 2009/03/24 ---------------------
這次主要對bellagio的做法加以了解,看是如何去驅動每個component去做初始化,連結,執行等等,為了之後看是否能使slim的架構上能夠讓OMX components 加個adapter 就能夠與slim的component 相連。並且思考該怎麼去實作。還必須要搞懂slim中如何去操作component,之前只有個概念而已。之後多找個時間看一下。
--------------------- 2009/04/07 ---------------------
報告目前進度,之前是將Bellagio的編譯環境建起來,並粗略去trace他其中一個寫好的系統,就是撥放audio的專案,目前是想先去試著將某一部分的功能試著在slim上面寫,還在嘗試的階段,先不考慮到OpenMAX component與slim中的component作連結,先試著把Bellagio中專案拆開到slim上就好,之後,還需要研究一下如何將OpenMAX中傳遞資料的"buffer"轉換成slim中的data channel和 signal channel。
--------------------- 2009/05/19 ---------------------
這次終於算是把OMX的mp3元件兜起來了,目前也把他掛在slim上可以正常work了,想一下做這麼久的原因,是一開始對mp3 decoder順序及特性的不熟悉,以及對OMX所規定的函數參數傳進傳出的不熟悉。目前有拿過不同類型的mp3去執行。到目前是都可以正常播放的,不過有去利用slim原本提供的mp3 decoder做比較,都分別將pcm檔輸出做比較,檔案內容不太一樣,可是去看一下波形兩個的差異不大。
--------------------- 2009/05/29 ---------------------
列一下目前知道可用的codec:
ARM OpenMAX_DL Sample Code
AC(Audio Coding)
mp3
aac
VC(Video Coding)
Common
MPEG4 Part2
MPEG4 Part10
IC(Image Coding)
JPEG codec
FFmpeg那個我不知道該怎麼列,太多不懂的格式了,直接列出他程式碼的一段提到他的codec格式,覺得需要什麼在去挖看看有沒有。
/* video codecs */
REGISTER_DECODER (AASC, aasc);
REGISTER_DECODER (AMV, amv);
REGISTER_ENCDEC (ASV1, asv1);
REGISTER_ENCDEC (ASV2, asv2);
REGISTER_DECODER (AVS, avs);
REGISTER_DECODER (BETHSOFTVID, bethsoftvid);
REGISTER_DECODER (BFI, bfi);
REGISTER_ENCDEC (BMP, bmp);
REGISTER_DECODER (C93, c93);
REGISTER_DECODER (CAVS, cavs);
REGISTER_DECODER (CINEPAK, cinepak);
REGISTER_DECODER (CLJR, cljr);
REGISTER_DECODER (CSCD, cscd);
REGISTER_DECODER (CYUV, cyuv);
REGISTER_ENCDEC (DNXHD, dnxhd);
REGISTER_DECODER (DSICINVIDEO, dsicinvideo);
REGISTER_ENCDEC (DVVIDEO, dvvideo);
REGISTER_DECODER (DXA, dxa);
REGISTER_DECODER (EACMV, eacmv);
REGISTER_DECODER (EATGQ, eatgq);
REGISTER_DECODER (EATGV, eatgv);
REGISTER_DECODER (EATQI, eatqi);
REGISTER_DECODER (EIGHTBPS, eightbps);
REGISTER_DECODER (EIGHTSVX_EXP, eightsvx_exp);
REGISTER_DECODER (EIGHTSVX_FIB, eightsvx_fib);
REGISTER_DECODER (ESCAPE124, escape124);
REGISTER_ENCDEC (FFV1, ffv1);
REGISTER_ENCDEC (FFVHUFF, ffvhuff);
REGISTER_ENCDEC (FLASHSV, flashsv);
REGISTER_DECODER (FLIC, flic);
REGISTER_ENCDEC (FLV, flv);
REGISTER_DECODER (FOURXM, fourxm);
REGISTER_DECODER (FRAPS, fraps);
REGISTER_ENCDEC (GIF, gif);
REGISTER_ENCDEC (H261, h261);
REGISTER_ENCDEC (H263, h263);
REGISTER_DECODER (H263I, h263i);
REGISTER_ENCODER (H263P, h263p);
REGISTER_DECODER (H264, h264);
REGISTER_DECODER (H264_VDPAU, h264_vdpau);
REGISTER_ENCDEC (HUFFYUV, huffyuv);
REGISTER_DECODER (IDCIN, idcin);
REGISTER_DECODER (INDEO2, indeo2);
REGISTER_DECODER (INDEO3, indeo3);
REGISTER_DECODER (INTERPLAY_VIDEO, interplay_video);
REGISTER_ENCDEC (JPEGLS, jpegls);
REGISTER_DECODER (KMVC, kmvc);
REGISTER_ENCODER (LJPEG, ljpeg);
REGISTER_DECODER (LOCO, loco);
REGISTER_DECODER (MDEC, mdec);
REGISTER_DECODER (MIMIC, mimic);
REGISTER_ENCDEC (MJPEG, mjpeg);
REGISTER_DECODER (MJPEGB, mjpegb);
REGISTER_DECODER (MMVIDEO, mmvideo);
REGISTER_DECODER (MOTIONPIXELS, motionpixels);
REGISTER_DECODER (MPEG_XVMC, mpeg_xvmc);
REGISTER_ENCDEC (MPEG1VIDEO, mpeg1video);
REGISTER_ENCDEC (MPEG2VIDEO, mpeg2video);
REGISTER_ENCDEC (MPEG4, mpeg4);
REGISTER_DECODER (MPEGVIDEO, mpegvideo);
REGISTER_DECODER (MPEG_VDPAU, mpeg_vdpau);
REGISTER_DECODER (MPEG1_VDPAU, mpeg1_vdpau);
REGISTER_ENCDEC (MSMPEG4V1, msmpeg4v1);
REGISTER_ENCDEC (MSMPEG4V2, msmpeg4v2);
REGISTER_ENCDEC (MSMPEG4V3, msmpeg4v3);
REGISTER_DECODER (MSRLE, msrle);
REGISTER_DECODER (MSVIDEO1, msvideo1);
REGISTER_DECODER (MSZH, mszh);
REGISTER_DECODER (NUV, nuv);
REGISTER_ENCODER (PAM, pam);
REGISTER_ENCODER (PBM, pbm);
REGISTER_DECODER (PCX, pcx);
REGISTER_ENCODER (PGM, pgm);
REGISTER_ENCODER (PGMYUV, pgmyuv);
REGISTER_ENCDEC (PNG, png);
REGISTER_ENCODER (PPM, ppm);
REGISTER_DECODER (PTX, ptx);
REGISTER_DECODER (QDRAW, qdraw);
REGISTER_DECODER (QPEG, qpeg);
REGISTER_ENCDEC (QTRLE, qtrle);
REGISTER_ENCDEC (RAWVIDEO, rawvideo);
REGISTER_DECODER (RL2, rl2);
REGISTER_ENCDEC (ROQ, roq);
REGISTER_DECODER (RPZA, rpza);
REGISTER_ENCDEC (RV10, rv10);
REGISTER_ENCDEC (RV20, rv20);
REGISTER_DECODER (RV30, rv30);
REGISTER_DECODER (RV40, rv40);
REGISTER_ENCDEC (SGI, sgi);
REGISTER_DECODER (SMACKER, smacker);
REGISTER_DECODER (SMC, smc);
REGISTER_ENCDEC (SNOW, snow);
REGISTER_DECODER (SP5X, sp5x);
REGISTER_DECODER (SUNRAST, sunrast);
REGISTER_ENCDEC (SVQ1, svq1);
REGISTER_DECODER (SVQ3, svq3);
REGISTER_ENCDEC (TARGA, targa);
REGISTER_DECODER (THEORA, theora);
REGISTER_DECODER (THP, thp);
REGISTER_DECODER (TIERTEXSEQVIDEO, tiertexseqvideo);
REGISTER_ENCDEC (TIFF, tiff);
REGISTER_DECODER (TRUEMOTION1, truemotion1);
REGISTER_DECODER (TRUEMOTION2, truemotion2);
REGISTER_DECODER (TSCC, tscc);
REGISTER_DECODER (TXD, txd);
REGISTER_DECODER (ULTI, ulti);
REGISTER_DECODER (VB, vb);
REGISTER_DECODER (VC1, vc1);
REGISTER_DECODER (VC1_VDPAU, vc1_vdpau);
REGISTER_DECODER (VCR1, vcr1);
REGISTER_DECODER (VMDVIDEO, vmdvideo);
REGISTER_DECODER (VMNC, vmnc);
REGISTER_DECODER (VP3, vp3);
REGISTER_DECODER (VP5, vp5);
REGISTER_DECODER (VP6, vp6);
REGISTER_DECODER (VP6A, vp6a);
REGISTER_DECODER (VP6F, vp6f);
REGISTER_DECODER (VQA, vqa);
REGISTER_ENCDEC (WMV1, wmv1);
REGISTER_ENCDEC (WMV2, wmv2);
REGISTER_DECODER (WMV3, wmv3);
REGISTER_DECODER (WMV3_VDPAU, wmv3_vdpau);
REGISTER_DECODER (WNV1, wnv1);
REGISTER_DECODER (XAN_WC3, xan_wc3);
REGISTER_DECODER (XL, xl);
REGISTER_ENCDEC (ZLIB, zlib);
REGISTER_ENCDEC (ZMBV, zmbv);
/* audio codecs */
REGISTER_DECODER (AAC, aac);
REGISTER_ENCDEC (AC3, ac3);
REGISTER_ENCDEC (ALAC, alac);
REGISTER_DECODER (APE, ape);
REGISTER_DECODER (ATRAC3, atrac3);
REGISTER_DECODER (COOK, cook);
REGISTER_DECODER (DCA, dca);
REGISTER_DECODER (DSICINAUDIO, dsicinaudio);
REGISTER_DECODER (EAC3, eac3);
REGISTER_ENCDEC (FLAC, flac);
REGISTER_DECODER (IMC, imc);
REGISTER_DECODER (MACE3, mace3);
REGISTER_DECODER (MACE6, mace6);
REGISTER_DECODER (MLP, mlp);
REGISTER_DECODER (MP1, mp1);
REGISTER_ENCDEC (MP2, mp2);
REGISTER_DECODER (MP3, mp3);
REGISTER_DECODER (MP3ADU, mp3adu);
REGISTER_DECODER (MP3ON4, mp3on4);
REGISTER_DECODER (MPC7, mpc7);
REGISTER_DECODER (MPC8, mpc8);
REGISTER_ENCDEC (NELLYMOSER, nellymoser);
REGISTER_DECODER (QCELP, qcelp);
REGISTER_DECODER (QDM2, qdm2);
REGISTER_DECODER (RA_144, ra_144);
REGISTER_DECODER (RA_288, ra_288);
REGISTER_DECODER (SHORTEN, shorten);
REGISTER_DECODER (SMACKAUD, smackaud);
REGISTER_ENCDEC (SONIC, sonic);
REGISTER_ENCODER (SONIC_LS, sonic_ls);
REGISTER_DECODER (TRUESPEECH, truespeech);
REGISTER_DECODER (TTA, tta);
REGISTER_DECODER (VMDAUDIO, vmdaudio);
REGISTER_ENCDEC (VORBIS, vorbis);
REGISTER_DECODER (WAVPACK, wavpack);
REGISTER_ENCDEC (WMAV1, wmav1);
REGISTER_ENCDEC (WMAV2, wmav2);
REGISTER_DECODER (WS_SND1, ws_snd1);
/* PCM codecs */
REGISTER_ENCDEC (PCM_ALAW, pcm_alaw);
REGISTER_DECODER (PCM_DVD, pcm_dvd);
REGISTER_ENCDEC (PCM_F32BE, pcm_f32be);
REGISTER_ENCDEC (PCM_F32LE, pcm_f32le);
REGISTER_ENCDEC (PCM_F64BE, pcm_f64be);
REGISTER_ENCDEC (PCM_F64LE, pcm_f64le);
REGISTER_ENCDEC (PCM_MULAW, pcm_mulaw);
REGISTER_ENCDEC (PCM_S8, pcm_s8);
REGISTER_ENCDEC (PCM_S16BE, pcm_s16be);
REGISTER_ENCDEC (PCM_S16LE, pcm_s16le);
REGISTER_DECODER (PCM_S16LE_PLANAR, pcm_s16le_planar);
REGISTER_ENCDEC (PCM_S24BE, pcm_s24be);
REGISTER_ENCDEC (PCM_S24DAUD, pcm_s24daud);
REGISTER_ENCDEC (PCM_S24LE, pcm_s24le);
REGISTER_ENCDEC (PCM_S32BE, pcm_s32be);
REGISTER_ENCDEC (PCM_S32LE, pcm_s32le);
REGISTER_ENCDEC (PCM_U8, pcm_u8);
REGISTER_ENCDEC (PCM_U16BE, pcm_u16be);
REGISTER_ENCDEC (PCM_U16LE, pcm_u16le);
REGISTER_ENCDEC (PCM_U24BE, pcm_u24be);
REGISTER_ENCDEC (PCM_U24LE, pcm_u24le);
REGISTER_ENCDEC (PCM_U32BE, pcm_u32be);
REGISTER_ENCDEC (PCM_U32LE, pcm_u32le);
REGISTER_ENCDEC (PCM_ZORK , pcm_zork);
/* DPCM codecs */
REGISTER_DECODER (INTERPLAY_DPCM, interplay_dpcm);
REGISTER_ENCDEC (ROQ_DPCM, roq_dpcm);
REGISTER_DECODER (SOL_DPCM, sol_dpcm);
REGISTER_DECODER (XAN_DPCM, xan_dpcm);
/* ADPCM codecs */
REGISTER_DECODER (ADPCM_4XM, adpcm_4xm);
REGISTER_ENCDEC (ADPCM_ADX, adpcm_adx);
REGISTER_DECODER (ADPCM_CT, adpcm_ct);
REGISTER_DECODER (ADPCM_EA, adpcm_ea);
REGISTER_DECODER (ADPCM_EA_MAXIS_XA, adpcm_ea_maxis_xa);
REGISTER_DECODER (ADPCM_EA_R1, adpcm_ea_r1);
REGISTER_DECODER (ADPCM_EA_R2, adpcm_ea_r2);
REGISTER_DECODER (ADPCM_EA_R3, adpcm_ea_r3);
REGISTER_DECODER (ADPCM_EA_XAS, adpcm_ea_xas);
REGISTER_ENCDEC (ADPCM_G726, adpcm_g726);
REGISTER_DECODER (ADPCM_IMA_AMV, adpcm_ima_amv);
REGISTER_DECODER (ADPCM_IMA_DK3, adpcm_ima_dk3);
REGISTER_DECODER (ADPCM_IMA_DK4, adpcm_ima_dk4);
REGISTER_DECODER (ADPCM_IMA_EA_EACS, adpcm_ima_ea_eacs);
REGISTER_DECODER (ADPCM_IMA_EA_SEAD, adpcm_ima_ea_sead);
REGISTER_DECODER (ADPCM_IMA_ISS, adpcm_ima_iss);
REGISTER_ENCDEC (ADPCM_IMA_QT, adpcm_ima_qt);
REGISTER_DECODER (ADPCM_IMA_SMJPEG, adpcm_ima_smjpeg);
REGISTER_ENCDEC (ADPCM_IMA_WAV, adpcm_ima_wav);
REGISTER_DECODER (ADPCM_IMA_WS, adpcm_ima_ws);
REGISTER_ENCDEC (ADPCM_MS, adpcm_ms);
REGISTER_DECODER (ADPCM_SBPRO_2, adpcm_sbpro_2);
REGISTER_DECODER (ADPCM_SBPRO_3, adpcm_sbpro_3);
REGISTER_DECODER (ADPCM_SBPRO_4, adpcm_sbpro_4);
REGISTER_ENCDEC (ADPCM_SWF, adpcm_swf);
REGISTER_DECODER (ADPCM_THP, adpcm_thp);
REGISTER_DECODER (ADPCM_XA, adpcm_xa);
REGISTER_ENCDEC (ADPCM_YAMAHA, adpcm_yamaha);
/* subtitles */
REGISTER_ENCDEC (DVBSUB, dvbsub);
REGISTER_ENCDEC (DVDSUB, dvdsub);
REGISTER_DECODER (XSUB, xsub);
/* external libraries */
REGISTER_ENCDEC (LIBAMR_NB, libamr_nb);
REGISTER_ENCDEC (LIBAMR_WB, libamr_wb);
REGISTER_ENCDEC (LIBDIRAC, libdirac);
REGISTER_ENCODER (LIBFAAC, libfaac);
REGISTER_DECODER (LIBFAAD, libfaad);
REGISTER_ENCDEC (LIBGSM, libgsm);
REGISTER_ENCDEC (LIBGSM_MS, libgsm_ms);
REGISTER_ENCODER (LIBMP3LAME, libmp3lame);
REGISTER_DECODER (LIBOPENJPEG, libopenjpeg);
REGISTER_ENCDEC (LIBSCHROEDINGER, libschroedinger);
REGISTER_DECODER (LIBSPEEX, libspeex);
REGISTER_ENCODER (LIBTHEORA, libtheora);
REGISTER_ENCODER (LIBVORBIS, libvorbis);
REGISTER_ENCODER (LIBX264, libx264);
REGISTER_ENCODER (LIBXVID, libxvid);
28 則留言:
清參考一下我在阿凡那串的留言.
你的ppt看不到.
Buffett找到的information.
PacketVideo OpenCORE 2.0 Multimedia Sub-system for Android
PacketVideo (PV) introduced OpenCORE 2.0 multimedia sub-system for Android. OpenCORE provides the essential media features for device development and enables playing and streaming of standard formats, recording of images and video, and more. The new video telephony features a two-way engine for circuit switched video telephony, enabling video telephony applications based on the 3G-324M protocol. OpenCORE 2.0 also supports encoders using the industry-supported OpenMAX IL API, which enhances the ability to take advantage of available multimedia hardware acceleration to achieve the best possible performance.
Typical integration with OpenMAX IL core involves an entire set of audio and video codes. Now, with OpenCORE 2.0, the process is simplified and multiple OpenMAX cores can more easily coexist and function within the multimedia framework, making it easier and faster to add support for new devices and chipsets while extending the reach of Android.
In addition, OpenCORE 2.0 includeswider support of runtime-loadable components, which makes it easier to add new capabilities through stand-alone plugins. It features an improved media clock implementation to simplify the A/V synchronization and other timer-based logic, incorporation of improvements from interoperability testing, and performance and security improvements
我還是對OpenCL好奇.
請說明一下昨天meeting決定做的方式.
我再想, 我們的DSP可以用嗎? 張大緯老師他們有一個Socle的ARM版子, porting Linux後, OpenMax可以上嗎?
這點可以問一下mobo. 因為他們的也是ARM.
buffett:
我有一個疑問, OpenCore是用OPenMax DL那層的規格來實作, 還是不用呢?
另外, OpenCore supports AL的tool chain (如 GSstreamer或SLIM這樣的東西)呢? 還是只用Android的環境?
他對multicore的使用的support如何?
老師,我想你誤會了,PacketVideo的OpenCore是純SW的solution,我瞄了一下使用文件,看來只是把OpenMax的架構/codec搬過去而已,因為PacketVideo原本就是提供Android上的embedded multimedia solution的公司,所以不牽涉到HW。
關於OpenMax DL,我說明一下(但我得說這是我瞄一下文件後對它粗淺的認知 :p 所以可能會有誤解),其實我們看到的圖最下面那層左邊是Codec,右邊是Codec->OpenMax DL,在我來看意義是一樣的,OpenMax提供 Codec的介面及實作,所以你可以直接把這份程式編譯後,放到General CPU上去執行,這也是一種OpenMax DL;亦或你底層有HW accelerator,且把實作改成將資料送到accelerator去運算,算完再搬回來,那這也是在OpenMAX DL要做的事。但唯一不能改變的是OpenMax所訂的Codec function and interface。再澄清一下,這兒說的interface是指function call要傳遞的arguments。
OpenMAX DL把Codec分為五類
* AC - Audio Codecs (MP3 decoder and AAC decoder components)
* IC - Image Codecs (JPEG components)
* IP - Image Processing (Generic image processing functions)
* SP - Signal Processing (Generic audio processing functions)
* VC - Video Codecs (H264 and MP4 components)
像他在image processing裡就有訂義
Prototype
OMXResult omxICJP_DCTQuantFwd_S16 (const OMX_S16 *pSrc, OMX_S16 *pDst, const
OMX_U16 *pQuantFwdTable);
Description
Computes the forward DCT and quantizes the output coefficients for 8-bit image data; processes a single
8x8 block.
Input Arguments
• pSrc – pointer to the input data block (8x8) buffer; must be arranged in raster scan order and 8-byte
aligned. The input components should be bounded on the interval [-128, 127].
• pQuantFwdTable – pointer to the 64-entry quantization table generated using
DCTQuantFwdTableInit; must be aligned on an 8-byte boundary.
Output Arguments
• pDst – pointer to the output transform coefficient block (8x8) buffer; must be 8-byte aligned. The
output 8x8 matrix is the transpose of the explicit result; this transpose will be handled in Huffman
encoding.
Returns
• OMX_Sts_NoErr – no error
• OMX_Sts_BadArgErr – Bad arguments. Returned for any of the following conditions:
— a pointer was NULL
— one of the following pointers not 8-byte aligned: pSrc, pDst, or pQuantFwdTable
所以老師您一直想把OpenMax架到cuda,我覺得做的事就是在DL這一層,把資料送到cuda上去算而已。至於IL做什麼事,這得再來去翻翻文件。
I took a glance at the OpenMax IL document, but I don't get many ideas.
In my opinion, it may be quick and useful if 阿凡 digs into example codes.
Khronos group 網頁提到
OpenCL (Open Computing Language) is the first open, royalty-free standard for general-purpose parallel programming of heterogeneous systems. OpenCL provides a uniform programming environment for software developers to write efficient, portable code for high-performance compute servers, desktop computer systems and handheld devices using a diverse mix of multi-core CPUs, GPUs, Cell-type architectures and other parallel processors such as DSPs.
而在GPU這方面來說只能說cuda比較多人在做,另外ati也有他的GPU開發方案像是CTM(這方面就先跳過)
且因為有許多model都類似於cuda只是名稱不太一樣才會讓人誤會,不過畢竟OpenCL是個開放的標準而cuda only for nvidia GPGPU,且照OpenCL的描述,所寫出來的程式可以跑在GPU上,改天也可以跑在Cell BE上,而cuda只能用他的板子(不過"我的看法" OpenCL跟OpenMAX DL差不多只是寫general-purpose program 那如果我們想用GPGPU的話,底層還是自己要用cuda下去實做,而OpenCL與OpenMAX DL讓我覺得這兩個東西很曖昧)
而目前我們是可以是透過DL底層利用cuda來實做,所以走的是架構圖中右邊的部份,且DL層中已經定義好了各個的function name我們只需要實做這些function的內容就好,之後就必須試著將slim中component的function改用DL的介面來呼叫,基本上就算是實做出DL層的東西了,以後slim要proting到其他架構上面只需重新改寫DL interface就可以了,而slim中的component架構是不是要改用IL中的標準來做?若有想要跟別人的component結合的話就必須改了,可是覺得slim中的component架構算是淺顯易懂,而且目前我們有tool可以快速建立起一個component跟連結,這一部份就要看未來要怎麼去決定.
個人覺得如果目標只是鎖定在讓slim可以在多個平台上跑,可以往OpenCL這邊看
如果是在於想要與別人的component連接 可以往OpenMAX這邊看
那如果兩個都想要勒...恩..OpenMAX可能不能滿足喔
好吧! 需求要先講清楚.
第一. 保留訓練未來學生的平台, 也就是能自己做, 不被牽著鼻子的 盡量自己做.
2. 運用OpenMax上現有的Codec
3. 學習DL怎麼做, 以便自己的Algorithms與硬體可以接上來.
根據塞公講的, OpenCl要跨那麼多東西, 我怕最後落得像 CORBA 一樣, 而且才剛開始,mmm. 老實說, 一份code不大量修改可以跨X86, GPU, cell且運作如常, 我不太相信, 這裡有人相信嗎?
假如採用OpenMax的IL components, 那麼SLIM應該剩下一個介面, 過去的code多半不能用了. 而且OpenMax對類似SLIM這種filter based的架構支援度較差. 塞公也覺得SLIM的component簡單易懂, 丟掉可惜.
唉! 希望bff, keiko, 塞公,...不是要安慰我才說SLIM好.
所以, 假如OpenMax IL不用, 而踩用SLIM的原來的component架構是最能保留SLIM的精神的. 我們只需要熟悉DL的規格做法就可以做出跟其他人提供的硬體來連, 也可以做出用 GPU or cell的給其他用OpenMax IL的人用. 假如不用DL, 也可以參考OpenMax 下端左邊的做法, 比較沒相容性, 但是也許比較自由.
這樣, SLIM有了新的意義與版本, 功能變強了, 我們缺的一些元件可以用OpenMax既有的補一部分. 以後再加過去做過的演算法以及以後開發的.
對嗎? 請塞公先上來詳細一點講. 也請大家發表意見.
基本上,依照我們的需求(擴充slim可用的codec)與限制(希望保留slim架構),OpenMAX DL算是符合我們目前的需求,因為他只是定義所有codec的function name只需各家廠商去實做內容,目前基本上就是改一點slim有關codec中的程式,與利用cuda去實做function內容。雖然目前只找到只有ARM提供最簡單的codec可以給我們用,好像比較進階的codec需要一點費用才能取得,而其他DSP我就不曉得了。
而OpenCL,有興趣的可以看一下這篇的介紹http://heresy.spaces.live.com/blog/cns!E0070FB8ECF9015F!4487.entry 雖然不是很完美,但可以知道基本架構。不提很多大公司都投入這個計畫。目前AMD的ATI已經有ATI Stream宣稱要支援OpenCL了 對於ATI Stream有興趣的可以看一下這篇http://heresy.spaces.live.com/blog/cns!E0070FB8ECF9015F!5628.entry 雖然只是稍微介紹一下而已。
老師要買ATI的顯卡來玩玩了嗎 = =+
等你把CUDA玩熟, 而且玩不累, 我就買ATI的給你玩. 跟我同學交關一下也是應該的.
咦! OpenMax component與SLIM component做連結? 我有弄錯嗎? 我們不是要取代掉OpenMax 的IL嗎?
還是你要照DNA建議的在OpenMax 元件外包一層變SLIM component?
還是....? 我哪裡沒看懂?
唔?取代掉OpenMax的IL??這句話不太懂老師的意思。
還是我搞錯方向了,我目前是想說為了使slim能夠使用Bellagio中已經寫好現成的component,其實就等於是在做跟gstreamer一樣的事情,將OpenMax他們自定義的component結構,透過某種方式轉換成我們slim中的component結構,使得slim能夠"支援" Bellagio所提供的component。而這一部份做的事情只是將component架構間的轉換,如果有要關於OpenMax DL 目前還沒有對這一部份有做處理的部分,要注意的是,就算是我們把Bellagio component移植到slim上,我們依然沒有與OpenMax DL有任何的關係,因為他裡面codec實作部分也是呼叫系統中可以用的library,並沒有去使用OpenMax DL所定義的Interface。
找老師談後,發現自己做錯方向了,重點不是在OpenMAX IL的component,而是在使用OpenMAX DL的API,因為SLIM具有mutlithread的架構,所以如果配合使用OpenMAX DL或許可以增加component執行效率,也可以支援component於多平台共同執行。在要實作部分時,走錯方向去研究了。變成怎麼去研究與IL作連接。所以接下來部分,會先對slim中component部分先做一些API改寫 for X86 cpu,之後再實作其他硬體架構。
THX.
可是我怎麼覺得你還是沒說道我們講的很多重點, 很多重要的事情是在那邊顯現的, 這麼做與記錄是在追蹤自己的思為喔!合況我講的其實是當初你建議給我跟Buffett聽的, 我可是沒加什麼的.
所以除了這些, 請把你要做的流程記錄一下.
先說一下目的是要做什麼好了。
主要目前在OpenMAX component架構中,我們目前只需要OpenMAX DL上的需求,也就是將我們slim component裡面有關於到multimedia的function改寫以OpenMAX DL的API以符合OpenMAX DL標準,即達成部分元件加速,並且可以實現在不同平台上。這就是我們的目的。
要做的流程:
先開始把一兩個slim component程式呼叫名稱都改成OpenMAX DL api
然後只先去把這些api實作出來for linux
其他平台上的實作在之後的進度再來決定
我們討論過的怎麼沒update呢?
目前先以slim的component架構包底層OpenMAX DL的API,是先拿有人實做出來的API來將具有mp3decoder功能的slim component寫出來。之後只需替換自己實做的API內容就可以了,API實做內容可以按照自己需要平台寫出對應的程式碼。即可達成部分元件可跨平台或針對該元件加速的功能。
dear all:
在網路上找資料時看到這個討論
又從 "http://ludwig.csie.ncku.edu.tw/members/gary750301/Introduction of SLIM.pdf"
大致瞭解SLIM
從slides看來基本上SLIM 比較接近 gstreamer這類完整的media framework
而OpenMax AL/DL/IL其實只是 3 個 layer的標準, 並非一定要AL->IL 全部實作
AL - Audio/Vidio/Image playback/record
IL - components (ex: source, sink, filter in gstreamer), 提供component間的標準介面以實作元件 (ex: TI OpenMax-IL, Bellagio IL)
DL - low level building blocks
DL的目的在於提供codec HW dependent的AL, 如此新的硬體平台(DSP, CPU)只要提供DL implementation, 配合以DL 實作的codec, 即可迅速的實作各硬體平台的codec (ex: ARM OpenMax DL implementation)
老師在這提了3個需求
1. 保留訓練未來學生的平台, 也就是能自己做, 不被牽著鼻子的 儘量自己做.
基本上這不就是提出SLIM的目的? 否則採用現有的media framework即可, 所以我想只要不斷改良SLIM, 這點就不是問題.
2. 運用OpenMax上現有的Codec
這部份可以參考 gstreamer 的做法, gstreamer 實作了 openmax IL client(gst-openmax), 可以直接使用現有OpenMax-IL 實作(TI OpenMax IL or
Bellagio), 這也是設計IL的目的, 著名的beagleboard DSP demo 即為gstreamer + TI OpenMax-IL的結合(而Android中的OpenCore即是利用OpenMax-IL來整合codec component), 要達到這一步可以參考gstreamer的做法實作個slim-openmax
3. 學習DL怎麼做, 以便自己的Algorithms與硬體可以接上來.
這部份是與codec 內部以及硬體相關的部份, 要學習OpenMax DL怎麼實作, 基本上ARM NEON OpenMax DL library 就是最好的範例. 還有C Ref. 的實作版本. 然而比較可惜的是, 最好先以DL實作codec, 才能享受DL帶來的好處.
至於OpenCL 跨硬體平台的事情, 與CORBA問題不太一樣, OpenCL主要是因為它的做法類似於目前DirectX/OpenGL 2.x, DX 8,9,10/OpenGL 2.x 採用了shading language的方式, 有與hw及runtime 相關的compiler, 這也是最早GPGPU的Brook與之後Nvidia CUDA/ATI Stream的技術基礎. 所以硬體平台必須針對OpenCL 制定的Computing Language去實作compiler(在DX/OpenGL都有提供Shading Language的compiler)來達到這件事情. (目前Nvidia也宣佈要把PhysX
移植到OpenCL, 所以不會只有ATI有OpenCL Support)
而以CUDA/OpenCL 來與OpenMax 連結這方向, 在IL/DL 都是可行的.
Yen:
歡迎你來參與討論.
對新技術的引進與study純是為了同學可以研究新事物, 我相信這對一個碩士班生而言, 利用之找到好工作可能比理論研究做什麼要重要, 如您所說, 這是SLIM存活的最大理由. 所以我可能不管其他工具適不適合整到SLIM下面, 只要可以進來, 可以訓練學生, why not?
新的進度是, ARM提供的DL MP3現在可以進SLIM了, 未來是cuda吧! 我們人力不夠, 既要做研究, 又有三個Open source要維護與發展, 所以OpenCL就先擱下, 看看實際會怎麼樣再說.
歡迎你可以常來留言, 這樣可以告訴我們一些我們的盲點, 假如您有力氣與資源, 我們歡迎一切型式的合作. 我們的本意就是Open.
Open source, Open research, open framework, and of course open mind.
我也來說一下,在 slim與 openmax il 這一部分之前走錯路有看了一下,
兩個基本上是要由slim的component communication protocol轉換到OpenMAX IL的 component communication protocol而且必須考慮到兩邊buffer的製作與資源的管理也需要處理,必須要懂slim與OMX IL架構才比較好銜接,這部份比較麻煩。
目前主要是專注在硬體上的支援,所以會加入cuda部分,讓slim可以有component跨平台的特性。
老師, 我是梓鴻, 不需如此客氣
老師提到ARM OpenMax DL已經使用了MP3的部份, 而這又有學弟提到使用CUDA實作, 目前不知道老師所使用的硬體平台為何? 我之前買了張beagleboard, mobo因為工作關係現在也在使用, 是基於OMAP 3530 SoC的便宜板子(149 USD), 除了是ARM Core外 又因為是Cortex-A8 核心具有NEON support, 又有 TI C64+ DSP, 多樣的硬體支援, 我想作為研究平台也相當適合, 老師可以參考看看
看了看這裡一些關於課程的post, 讓我好生羨慕, 有機會還蠻想好好把一些東西看一看..:)
anyway, 大家加油.
給大家介紹一下這位學長.
Yen是成大第一屆大學部畢業的學長, 論資歷比我還資深. 品學兼優就不必說了.
老實說, 對於嵌入式, 我現在興趣小一點, 各式板子太多, 我不想維護這麼多版子, 導是希望軟體可以跨平台. 或說至少開發環境是在PC上. 目前的SLIM, OpenESL與正在做的Dataflow都是.
SLIM算是一個學習平台, 新的軟體開發就到這裡來, 我因為在電腦音樂應用尚需要大量計算, 所以先把CUDA弄進來. 目前買的PC多半可以支援, 最powerful的算是一張Tesla的卡.
至於OpenESL與DataFlow都是特殊應用軟體, 請挖一下相關舊聞, 或者出來吆喝一下, 自會有人出來答覆.
我想請你來當共同作者, OK? 來台南時, 別忘了來找我, 我跟你解釋一下我們在做什麼.
老師對於我的評價是過於抬舉我了
我唯一能拿來說的可能就是資歷吧
看老師在此語重心長地談到對於學生未來的工作的顧慮. 不免讓我回想從碩士, 當兵到現在工作資歷不到三年, 一路跌跌撞撞的過程, 在很多人看來浪費了不少時間, 到現在也沒甚麼稱得上的成就, 對我而言一切也只能說是人生際遇, 沒甚麼好說後不後悔. 在大學時, 我總是覺得技術學得太少, 而出來工作面對各樣挑戰, 又覺得書唸的不精, 在實務理論上感到書到用時方恨少. 真稱的上只有好奇心和對資工領域的一點熱忱. 即便在業界打滾, 然而真要說學甚麼會對以後非常有益, 我也無法給個定見.
共同作者, 當然是沒問題, 我只是怕寫不出對大家非常有助益的內容..
另外, 其實 5/1 假期, 我有開車南下帶老婆去台南遊玩, 與佳蓉打招呼後, 看老師在跟學弟妹們開會就先去找同學了, 沒想到與同學閒聊後老師已經離開辦公室, 當時沒跟老師打上招呼, 真的是很可惜
有機會南下, 當然也會找老師聊聊
看來ARM列的那些是基本的, 短期內我們可以做完這些就夠了. FFMPEG的要討論一下, 實在太多了.
我還有一個疑問就是, ARM的那些codec夠general嗎? 我的意思是說會不會她說可以解MPEG4, 可是卻碰到某些MPEG4 bitstream他不能解呢?
我對MPEG4不是很熟悉,不過我上次寫mp3的經驗,覺得這些都有照著spec上面的描述去寫,如果有說奇奇怪怪的bitstream的話,必須自己先處理好這些bitstream的排列再丟進arm的函式下去跑。例如mp3 unpack frameheader,就是明確說明必須丟進的bitstream必須是指到header的第一個bit,不會考慮說你這個mp3 decoder的bitstream來源是file open或者是網路串流。會按照spec上的header描述去解碼。例外像是解side_info,你只管丟進函式確定bitstream所只到的第一個bit是side_info的第一個bit就好。不管你前面的bit是屬於CRC部分還是header的尾巴。
不知道這樣有沒有解決老師的疑惑@_@!,因為不太知道MPEG4 bitstream會有多奇怪。
http://android.git.kernel.org/?p=platform/external/opencore.git;a=summary 這是opencore source link, 目前 opencore 已經改版至v2.04不過 omx mp3 decoder comp. 應該沒有太大改變, 請參考
Dawn 回文了!!
是呀! SCREAM Lab的黎明來了, 加油, 塞公, 這很希有的.
張貼留言