原來一直在看的幾個mpeg4解碼包，有ffmpeg，xvid和divx的，各有特點。ffmpeg兼容性（指h263dec.c）好能解各種格式的，包括divx和msmpegv3的，但是也帶來一定的複雜性，對於想做優化的人來說，拆解代碼的過程比較痛苦。xvid則相對簡單了許多，讀取碼流和核心代碼部分分離的很清楚，只支持avi格式,1.0.1以前的版本只支持I幀和P幀的解碼。從速度上來說ffmpeg要略快於xvid，原因是xvid在VLC解碼上做的優化和設計相對較少，查huffman表的時候都是選取了比較大的表，沒有進行分級處理。對於嵌入式應用只有8k,16kCache的處理器，效率相當低。我拿到的divx的代碼對VLC做了很好的優化，但是代碼分格太差，一個函數能夠傳上10幾個參數，不知道是不是真的是它們的商業版本？很早就下載下來了rmp4的包，這兩天才有時間看它，發現它集合了divx和xvid的優點，代碼可讀性好，速度比xvid要快，用純C代碼，在某款RISC處理器上播放QVGA(320x240)碼率500k的碼流2000幀時，xvid耗時42ms，rmp4耗時37ms。於是，又重新到網上search了一下，可以在這個地方下載到
http://www.sigmadesigns.com/products/RMP4_download.htm
下載下來的代碼是沒有Makefile的，只有VC的工程，但是俺不會用VC啊:( .又讀了讀它的接口，大致明白了怎麼回事，寫了個調用函數，在linux下編譯通過。
代碼封裝如下，有三個關鍵函數,我喜歡將之拿出來分別調用。
int RMP4_decoder(void * handle, int opt, void * param1)
{
switch (opt)
{
case MP4V_DEC_DECODE :
return RMP4_dec_processing((Decoder *) handle, (MP4V_DEC_FRAME*) param1);
case MP4V_DEC_CREATE :
return RMP4_dec_open((MP4V_DEC_PARAM *) param1);
case MP4V_DEC_DESTROY :
return RMP4_dec_close((Decoder *) handle);
default:
return MP4V_ERR_FAIL;
}
}
RMP4_dec_open：打開一個解碼器
傳入參數 MP4V_DEC_PARAM mp4_param;
主要是設置高和寬，就可以了
mp4_param.width=width;
mp4_param.height=height;
RMP4_dec_open(&mp4_param);該函數會給mp4_param.handle返回一個指針，可以做爲RMP4_dec_processing的第一個參數和RMP4_dec_close的參數，這個RMP4_dec_close當然是在退出程序的時候調用，不多解釋。
RMP4_dec_processing：這個函數是解碼一幀圖像
除了Decoder *handle參數外的，第二個參數是MP4V_DEC_FRAME mp4_frame主要配置輸入的碼流地址，碼流長度，輸出圖像地址，輸出圖像格式，還有輸出圖像的步長(stride，有的地方叫pitch)
mp4_frame.bitstream=bitstream;
mp4_frame.length=mp4_frame.length;
mp4_frame.image=output_buf;
mp4_frame.stride=stride;
mp4_frame.colorspace=MP4V_CSP_I420;//這個顏色空間有很多宏，按需要選一個
然後，調用
RMP4_dec_processing(mp4_param.handle,&mp4_frame);
當然，這個函數會調用很多次了，因爲每次只能解碼一幀:),所以必須自己來維護mp4_frame的位流指針和位流長度。要注意的是，每次調用完RMP4_dec_processing函數之後，mp4_frame的mp4_frame.length會被修改爲解碼一幀後用掉的字節數，所以下一幀解碼應該從位流的這個字節數後接着往下解碼。
好睏，沒有其它代碼了:(,俺家沒有編譯器。
轉自http://wangjiajun53880.blog.163.com/blog/static/11700139420106217565061/
