JM編碼器的介紹要點(diǎn)

1、圖目錄1概述62 JM編碼器的介紹7.2.1 JM編碼器主要流程 72.2 JM編碼在 VC中編譯過程 93 JM的編解碼過程.1.13.1 JM的編解碼過程 113.1.1 JM編碼過程113.1.2 JM解碼過程123.2 JM的輸岀文件格式 133.2.1基于比特流文件格式 133.2.2 RTP文件格式 153.3 JM的視頻質(zhì)量評(píng)估 163.4 JM的文件接口 錯(cuò)誤！未定義書簽。4問題解答 JM 能在 linux 下運(yùn)行么？ 184.2 JM編碼器對(duì)數(shù)據(jù)丟失的處理？ 184.3在下載的flv中為什么會(huì)只有 15fps ？ 184.4怎么設(shè)置 JM輸岀為固定碼速率？ 19

2、5參考資料20.圖2-1 JM編碼器主函數(shù)部分 8圖 2-2 JM 的 Encode_one _frame 函數(shù)部分9圖2-3 Project Setting 10圖3-1 JM編碼參數(shù)11圖3-2 JM編碼結(jié)果112圖3-3 JM編碼結(jié)果212圖3-4解碼結(jié)果 13圖3-5 NAL內(nèi)部防競(jìng)爭(zhēng)機(jī)制 14圖3-6 JM編碼后數(shù)據(jù)-1 14圖3-7基于比特流的文件格式 14圖3-8 RTP的格式15圖3-9 RTP負(fù)載頭部15圖3-10 PSNR求解結(jié)果 17圖3-11接口文件 錯(cuò)誤！未定義書簽。3表目錄15表 3-1 RTP 的 type 值4JM 編碼器關(guān)鍵詞： JM 編碼器、 JM 安裝、視

3、頻評(píng)估摘 要： 本報(bào)告主要對(duì) JM 編碼器做了比較詳細(xì)的介紹，包括其主要作用、安裝和使用過程、編解碼 過程及其文件輸出格式，并對(duì)其自帶的視頻的質(zhì)量評(píng)估作一個(gè)簡(jiǎn)單的介紹，并對(duì)整個(gè)編解碼的過程給出了 實(shí)例分析。縮略語(yǔ)清單：縮略語(yǔ) 英文全名 中文解釋CBRConstant bit rate固定比特速率FLVFlash videoFlash 視頻NALNetwork abstract layer網(wǎng)絡(luò)抽象層NALUNetwork abstract layer unit網(wǎng)絡(luò)抽象層單元PSNRPeak signal to noise ratio峰值信噪比RTPReal-time Transport prot

4、ocol實(shí)時(shí)傳輸協(xié)議51 概述JM編碼程序是H.264的官方測(cè)試源碼，由德國(guó) hhi研究所負(fù)責(zé)開發(fā) 。起始時(shí)間是2002年2月。JM 實(shí)現(xiàn)了 H.264所有的特性，幾乎所有的學(xué)術(shù)研究的算法都是在JM基礎(chǔ)上實(shí)現(xiàn)并和 JM進(jìn)行比較。但其程序結(jié)構(gòu)冗長(zhǎng)，只考慮引入各種新特性以提高編碼性能，忽視了編碼復(fù)雜度，其編碼復(fù)雜度極高， 不宜實(shí)用。本報(bào)告從JM編碼器的安裝和使用過程、JM的編碼流程、JM的文件輸出、JM中自帶的視頻評(píng)估策略等方面對(duì)JM編解碼器進(jìn)行了詳細(xì)的介紹，并給出了實(shí)例分析。本報(bào)告的章節(jié)結(jié)構(gòu)如下：第2章JM編碼器的介紹 介紹JM編碼程序主要流程和在 VC下編譯過程。第3章JM的編解碼過程 結(jié)合實(shí)

5、例對(duì)JM程序的編解碼過程、文件輸出格式、視頻評(píng)估機(jī)制的介紹。第4章參考資料 列出報(bào)告中引用的參考資料。62 JM編碼器的介紹JM編碼器是H.264官方發(fā)布的測(cè)試源碼，其實(shí)現(xiàn)了H.264建議的所有的特性，所以學(xué)術(shù)研究的算法都是在JM的基礎(chǔ)上進(jìn)行實(shí)現(xiàn)并和 JM源進(jìn)行比較，得出算法的優(yōu)缺點(diǎn)。 但是JM程序在編寫的時(shí)候就沒有 考慮效率，只是考慮引入各種新特性以提高編碼的性能而忽視了整個(gè)程序的復(fù)雜度，讓JM的編碼復(fù)雜度極高、運(yùn)行速度相當(dāng)慢。所以JM編碼器只適用于學(xué)術(shù)研究，沒有實(shí)用效果。2.1 JM編碼器主要流程整個(gè)JM編碼源就是一個(gè)總工程 ject，其下面又包含兩個(gè)子工程lencod.pr

6、oject和Iject。打開總工程tml.pjt中可以看到兩個(gè)子工程，分別編譯生成lencod.exe和ldecod.exe兩個(gè)可執(zhí)行文件。當(dāng)然ject和ject這兩個(gè)子工程也是完全獨(dú)立，各自包含各自的 C文件、主函數(shù)文件、H頭文件、配置文件，是可以獨(dú)立進(jìn)行編譯的。JM編碼器采用的是標(biāo)準(zhǔn)的C代碼格式，可以在wi ndows、lin ux、an droid等環(huán)境中進(jìn)行編譯， 而且JM編碼器的基本參數(shù)的選擇采用配置文件格式進(jìn)行提供，對(duì)編譯好的JM程序進(jìn)行參數(shù)修改時(shí)，只需要在配置文件中進(jìn)行修改即可，不需要重新編譯。JM提供了 baseline

7、、main、extended三種不同級(jí)別的配置文件，里面的基本參數(shù)的參考值也已經(jīng)提供。詳細(xì)的配置文件見附錄A。下面是JM編碼器的主要的流程圖：見圖2-1、圖2-2。JM編碼流程:圖2-1 JM編碼器主函數(shù)部分注：1. 這里主函數(shù)部分省略了一些函數(shù)的調(diào)用和條件判斷、釋放空間，判斷幀類型影響不大的部分。2. 率失真后的申請(qǐng)兩幀圖像的空間：一個(gè)是編碼幀，一個(gè)是參考幀。3. 在快速運(yùn)動(dòng)估計(jì)后面的閾值是為了在運(yùn)動(dòng)估計(jì)時(shí)給出一個(gè)判斷條件，小于閾值則進(jìn)行快速運(yùn)動(dòng) 估計(jì)，大于則放棄。21Encode_one _frame ()包括打開編碼文件、申請(qǐng)緩存, 讀取一幀數(shù)據(jù)等宏塊級(jí)別編碼:初始化/NAL打包或是RT

8、P打包寫入slice頭信息RTP打包格式最后一個(gè)宏塊?廠-Y Return運(yùn)動(dòng)估計(jì)和運(yùn)動(dòng)分析/分析各種運(yùn)動(dòng)預(yù)測(cè)下的開 銷，并尋求最優(yōu)MV計(jì)算殘差,DCT變換，量化及ZigZag掃描選擇CAVLC或CABAC進(jìn)行編碼選擇下一個(gè)宏塊圖 2-2 JM 的 Encode_one _frame函數(shù)部分注：1. 因?yàn)镴M可能采用率失真優(yōu)化，所以在每一幀編碼時(shí)，都要對(duì)量化參數(shù)進(jìn)行更新。2. H.264支持 NALU 打包和 RTP打包格式的。3. 在宏塊級(jí)別編碼的流程基本和x264程序一致。2.2 JM編碼在VC中編譯過程1. 首先下載并解壓 JM源代碼2. 在源代碼的根目錄下找到bin文件夾，新建一個(gè) b

9、ackup文件夾，并將bin文件中的所有文件復(fù)制到backup文件夾中做好備份。3. 在源代碼根目錄下新建lencodtest文件夾，將編碼過程中需要的配置文件(encoder.cfg)、待編碼的視頻序列(如 foreman_qcif.yuv )等復(fù)制該文件夾中。4. 在源代碼根目錄下新建ldecodtest文件夾，將解碼過程中需要的配置文件(decoder.cfg)、待解碼的文件(例如test.264)復(fù)制到該文件夾中。5. 打開源代碼根目錄下的tml.dsw。6. 分別選擇 lencod 和 Idecod 工程，鼠標(biāo)左鍵選中 lencod (Idecod)工程打開 Project ->

10、; Sett in gs -> Debug ,在 Working directory 選項(xiàng)中填寫./encodtest (./ldecodtest)，在 Program arguments 選項(xiàng)中填寫需要使 用的編碼配置文件(要與第3步所復(fù)制的文件同名)，例如：-d encoder.cfg (-d decoder.cfg)，然后確定修改。見圖2-3。7. 鼠標(biāo)右鍵選中l(wèi)encod (ldecod)工程，選擇鼠標(biāo)右鍵菜單 Set as Active Project。編譯運(yùn)行即可。圖 2-3 Project Setting3 JM的編解碼過程3.1 JM的編解碼過程3.1.1 JM編碼過程在

11、JM編碼器編譯通過的基礎(chǔ)上，首先打開tml.dsw，根據(jù)編碼要求修改其中的 encod.cfg文件，保存后退出。然后在cmd中找到JM的根目錄中的bin文件夾，然后直接輸入"lencod.exe”運(yùn)行即可。下面進(jìn) 行實(shí)例介紹：編碼參數(shù)為：編碼級(jí)別為baseline,編碼圖像序列為football_cif_30.yuv，編碼幀數(shù)為150幀，I幀周期test.264,輸出采用為 NALU格式打包，輸出為25,編碼幀率為25fps，量化參數(shù)為28，圖像輸出文件為重建圖像文件為test_rec.yuv。見圖3-1所示。InputFileInputHeStar tFr sueFramesToB

12、 eEnc aidedFrameRateSourceWidthSotirc eHeightTrac eFileR«confileOutputFileIntr aP er i o d ICRIntra£n4ble QFFir stFranie# Fil«sfootball_cif_3O.# Input sequence TUV 4；2；00# If tht inputfile has ast<t i V s length in bytg hre0# Start frame： for encoding. (0"M)150# Number of fram

13、es to be coded25# Frame Rate per second (l100)352# Iim&gg width in Fels must be multiple ef 16288# Inn生驢 height ixi Psls, must multiple of 16traceenc, tsct 旨. yuv"test.2e4# Encoder ControlFrfilelBC= 66 律 PrHle IDC66比裁"】衛(wèi)旬88=cKtde4)Uv«lIX= 30 # Uval IDC (e g 20 = leval 2. 0)=25# Pe

14、riod. o£ I_Framez tOonly first)=0 # Fores IDE Intr« (|0=dis4bl» l=«nabli)=26# Qu&nt. param for first frun« (intra) ©-51)圖3-1 JM編碼參數(shù)編碼結(jié)果如圖3-2和圖3-3:P-eir s infjConF ig-f i >e encodei-. Er-gj亠八八八八- - * - - ¥八.八八八八J nput 1File：&：Xf not hrtll_jc iF_3W - vuuOu

15、t： putH -264 bitstrean:test.264Output¥UUfilir-Ebet _rec & yuuOutputlegfOut|>utstat 1stics file:s tilt datFraneBitZpii; HF OPGnr¥SnrUSnrUT imrCmsi 3>FrMZFld1 D18413H&B8 B 28 3S _ 71439_87-14«.?43312SB：FRM39G0001<P>35448 0 2834.9539-549-i0,6se532®99?FRH1eeesKpj4

16、4&96 U 2 含4?1239a248-10.4577406113 SFRH1247960 B 2S 34.9B239.13S斗:L294383407FRH2倍H 2834.86339.0340, «111547-464?FRH225144 8 2834S153今.&5740.45113656596i&FRH28SS&V& B 28347723H.98Z-4U.SE3515718&¥2 &FRH科5B4M 0 2934 .75t39.KBjLSRAH蜩9FRH41S9&56 28 呂479838.99540.

17、53920&88丄 0£&FRH480a0<F>tl Zti 3：4b&1：B4W-477M曲t剛111W?FRHS5&2232 R 2fl號(hào)3B-944-10, OB2S1OT1Z<WFRH51W1KP>S1B24 6 2834.82438,97549.4362520312697FRH57U 2越34-92B39.1694W.SS?27HV31355SFfiH65Hfll3CP>S74G.4 0 293439.B1&4«.74627157izTfiaFRH5563784 S 28呂£39.14

18、340.5752784413572FRH5Si9Cfl5<P>&619U4 U3S.5H139.33713313PRnHl£217% 0 2835 . &2 439.3514Q.G1G32&2GS127HSFRMra0«17<P>&5456 0 2835.35339.345何49 730141isiseFRMaeiB<p>78S88 0 2834.9a39.154U.4B2zh'.i r.1413?FHHM19<F>B 28 3<l.7Gfr39.262d«.37S25B

19、2812783FRH¥30020<p>&29GO 0 2834.B0139-28?-10,572264»&13934FRM76BB2KF)59696 0 28 自；4 99539.30446.5642582S129&5FRH?0M«22<F>594BS B 2835_37fl39.3814H-7772&Z5B12951FRHblFl«23<r>60016 0 28 3SH4Hti40,7702596913B»FRH024<P>&4464 0 2 冷54743

20、9-36140.8582553112838FRH94EMSZSCO1E33168 B 283E.B59-SB-259141-4232B?fclBFRHSRRl R 2» 3b,26922132H4FRH圖3-2 JM編碼結(jié)果1圖3-3 JM編碼結(jié)果23.1.2 JM解碼過程在JM程序編譯通過后，先將要譯碼的文件放入Idecodtest文件夾下，打開tml.dsw，根據(jù)自己的參數(shù)（主要是譯碼文件的位置等）要求修改decoder.cfg文件，完成后保存退出。然后再 cmd中查找到JM根目錄下的 bin 文件夾，輸入"ldecod.exe decoder.cfg” 即可。卜面是對(duì)

21、上面編碼生成的test.264文件進(jìn)行解碼，解碼結(jié)杲見圖3-4:iaeeo WfrIHHIl丄舁WZH422SM 28M 2S22 282H 2S1北28284 2S2 2SR 2R=f i*Anie TOC QPmistI njYirit H.Zii-i hitat re Am Output decodEdl ¥IJU Out- put s-t«.t lls f i le Input referHnce filsDecodef conf ig flie0 0H-0H0 0flnDD00HHMM0HhHhHM忖HK- 8 R2 2 22212K- uM a:decoder石

22、Fg:t£St.2bd" tcst-dcc. 5FUU< * lo<< - dec: teEt_rec B yuwor f itsldtt for SNRs to h«SnrUfV<>1CP>2<P>3<P>4<FS<FJ6CP>7CP>ft<P>9CP> 1B<P> 11<P> iacFJ 13<P> I4CP> 15CP>17<P> ie<p> 19CFJZtKF 21<P>

23、22CP> 23<P> 鮎CPI 25C1>609 eem fjfwm HflfmHUHH HtinR tiuouUtMM6609 AOM 耐Cffil 時(shí)HH tlfrlHH HiHW66OS 6013 fiflm 耐仲n 朋HRFNIHfl RI RRHB 0 so麗 e 陽(yáng)盹 s WUH u 圏兇垃 Hl 60906<fWH祁 0 (W網(wǎng) n WRB R BOBB B 闔豳 e UUUld » WUt9 o 晦 000"mHfl Ft mRH ft0 OQOB H tMJtiB H HUH 迅 U WUU B 00096>ffilR

24、fl »腫胭 fl00009900 mm陰000900胭000BBB 0D0呂 甘四®09000900 CiH»A 評(píng)區(qū)內(nèi)0 朋0077B73y-73fiflB3y-2 0fi33334317fl2A515B18B1B0171BR0HH09S-_HH7 12 L2S-1S121221212222222 111圖3-4解碼結(jié)杲3.2 JM的輸出文件格式H.264的NAL單元定義了基于包（即RTP）和基于比特流（即.264文件）的基本格式，區(qū)別這兩種格式的 方法在于每個(gè)比特流傳輸層都有一個(gè)起始代碼。RTP格式文件主要用于傳輸，而.264文件格式主要用于存儲(chǔ)3。3.2.

25、1基于比特流文件格式H.264規(guī)定的基于比特流的文件主要用于數(shù)據(jù)存儲(chǔ)，NAL是依次緊密排列，解碼器將無法在數(shù)據(jù)流中分辨每個(gè)編碼數(shù)據(jù)是儲(chǔ)存在介質(zhì)NAL的起始和終止。（如 DVD光盤）上，由于H.264采用了一種簡(jiǎn)單而NAL前添加起始碼:有效的方案來解決這么問題。當(dāng)數(shù)據(jù)流是存儲(chǔ)在介質(zhì)上時(shí)，在每個(gè)0x000001同時(shí)H.264也定義了一個(gè)字節(jié) 0x00為zero_type,在一般的情況下2，NAL單元起始碼為 0x000001，只有在下面幾種情況下，會(huì)在NAL起始碼前加入zero_type，那樣NAL起始碼頭部變?yōu)?0x00000001。1. NAL單元的類型是 PPS或是SPS時(shí)。2. NAL單元

26、的類型是14-18。3. 每一幀圖像的第一個(gè) NAL單元即一個(gè)接入單元。4. NAL單元類型為SEI時(shí)。在這樣的機(jī)制下，解碼器在碼流中檢測(cè)起始碼，作為一個(gè)NAL的起始標(biāo)識(shí)，當(dāng)檢測(cè)到下一個(gè)起始碼時(shí)則標(biāo)志當(dāng)前 NAL結(jié)束。H.264規(guī)定當(dāng)檢測(cè)到0x000000時(shí)也可以表征當(dāng)前 NAL的結(jié)束，這是因?yàn)檫B著 的三個(gè)字節(jié)的0中的任何一個(gè)字節(jié)的 0要么屬于起始碼要么是起始碼前面添加的0。如果NAL內(nèi)部出現(xiàn)了 0x000001時(shí)，則會(huì)發(fā)生混淆，H.264提出了“防競(jìng)爭(zhēng)”。在NAL內(nèi)部出現(xiàn)0x000001 時(shí)，則在最后一個(gè)字節(jié)前插入一個(gè)新的字節(jié)：0x03，從而變成圖2-2所示。當(dāng)NAL解碼器遇到0x00000

27、3時(shí)，解碼器丟棄 0x03。0x0000000x0000010x0000020x0000030x000003000x000003010x000003020x00000303圖3-5 NAL內(nèi)部防競(jìng)爭(zhēng)機(jī)制注:0x000000是NAL的結(jié)束，0x000001是NAL起始碼，0x000002是H.264保留，0x000003是為了保證解 碼器正常。Offset01234567891011121314150000000他0000142 01E966160BO4A20000000000160001育A1438800000001因|88BD40"010000032BAB455B510EGB8DI

28、G5CE25S5AlBE00000048623A1B438001F&EuIDFDE0OC15EEZ72 OOOIOOS41EB39238618BB38EAE6A9FSC21A042E800000802550E38A4D50664D3BB9E82AE893F6F9圖3-6 JM編碼后數(shù)據(jù)-1上圖是本報(bào)告 3.1節(jié)中JM編碼后的數(shù)據(jù)，三個(gè)被標(biāo)記的 0x00000001是NALU的起始碼，67、68、65 分別是NALU的頭部信息，代表著第一個(gè) NALU是SPS信息，第二個(gè)NALU是PPS信息，第三個(gè)是IDR 幀。從圖3-6可以驗(yàn)證出基于比特流的文件格式為：0x00000001 &

29、0x000001NAL headerNAL playload圖3-7基于比特流的文件格式3.2.2 RTP文件格式RTP格式是H.264提供的適于網(wǎng)絡(luò)傳輸?shù)妮敵龈袷剑琑TP的文件格式如圖3-8所示，其中RTP的頭部信息在RFC 3550中有詳細(xì)的描述 ，包含1bit的標(biāo)志位、7bits的負(fù)載類型、16bits的序列號(hào)和32bits的時(shí) 間戳。對(duì)于RTP的負(fù)載，H.264規(guī)定了 3種不同的負(fù)載結(jié)構(gòu)，接收端可能通過RTP Payload的第一個(gè)字節(jié)即RTP負(fù)載頭部來識(shí)別它們，而這個(gè)字節(jié)類似NALU頭的格式，可以指出其代表的是哪種結(jié)構(gòu)。這個(gè)字節(jié)的結(jié)構(gòu)如圖3-9所示：RTP 頭部Payload圖3-8

30、 RTP的格式12345678FNRITYPE圖3-9 RTP負(fù)載頭部其中F為禁止位，NRI為重要等級(jí)位，TYPE的值為24-31，區(qū)別H.264中類型字段。RTP的type值的含義見表3-1所示：表 3-1 RTP 的 type 值TYPE 值類型解釋24STAP-A單一時(shí)間的組合包25STAP-B單一時(shí)間的組合包26MTAP16多時(shí)間組合包27MTAP24多時(shí)間組合包28FU-A分片的單元29FU-B分片的單元30-31沒有定義H. 264規(guī)定的3中結(jié)構(gòu)為單一的 NAL單元模式、組合封包模式、分片封包模式。I. 單一的 NAL單元模式：即一個(gè)RTP包僅由一個(gè)完整的 NALU組成，這種情況下

31、RTP的負(fù)載頭字段和 H.264的NALU類型字 段是一樣的。對(duì)于 NALU的長(zhǎng)度小于 MTU大小的包，一般采用單一 NAL單元模式。分裝時(shí)，只需要將 原始的H.264 NALU單元的起始碼去掉，然后將剩余的數(shù)據(jù)封裝成RTP包即可。2. 組合封包模式：即可能是由多個(gè) NAL單元組成一個(gè) RTP包，分別有四種組合方式STAP-A、STAP-B、MTAP16和MTAP24，其類型值分別為 24、25、26和27。STAP-A和STAP-B只含有一個(gè) NALU 時(shí)間戳，多個(gè) NAL 單元共享一個(gè) NALU時(shí)刻。MTAP16、MTAP24均含16bits的無符號(hào)解碼順序號(hào)、一個(gè)或多個(gè)多時(shí)刻聚合 單元和

32、16bits或24bits的時(shí)間戳位移。3. 分片圭寸包模式：用于將一個(gè)NALU單元分裝成多個(gè) RTP包，存在兩種類型FU-A和FU-B，其類型值分別為 28和29。 當(dāng)NALU的長(zhǎng)度超過 MTU時(shí)，就會(huì)對(duì)NALU進(jìn)行分片封包，每一個(gè)分片由整數(shù)個(gè)連續(xù)的NAL單元字節(jié)組成。相同的NAL單元分片必須使用遞增的 RTP序號(hào)連續(xù)順序發(fā)送，同樣 NAL單元必須按照RTP順序 號(hào)的順序裝配。3.3 JM的視頻質(zhì)量評(píng)估JM編碼器中自帶的視頻質(zhì)量評(píng)估機(jī)制包括PSNR （包括Y、U、V和總體的PSNR）、bit rate等。圖像的PSNR是指原圖像和處理圖像之間均方誤差相對(duì)于2552的對(duì)數(shù)值。其計(jì)算公式如式（3

33、-1）:2PSNR = 10log1°（255 /MSE）（3-1）在JM中對(duì)于在求解PSNR時(shí)，先設(shè)定一個(gè)參考文件（一般是解碼前或傳送前的那個(gè)文件），然后與解碼后的文件進(jìn)行比較才能得到相應(yīng)的PSNR。在一般情況下，PSNR按照式（3-1）進(jìn)行計(jì)算，但下面兩種情況PSNR的值將會(huì)設(shè)定為0。1）你沒有指定有效的參考文件； 2）解碼的文件與參考文件完全相同。若 在丟包后計(jì)算PSNR，就必須先進(jìn)行錯(cuò)誤隱藏才能計(jì)算。Bit rate也是評(píng)估視頻質(zhì)量的重要方面，在圖像質(zhì)量相同的前提下，實(shí)現(xiàn) bit rate越低也是實(shí)現(xiàn)視頻壓縮率高低一個(gè)重要體現(xiàn)。從圖3-4可以看出，其 PSNR值為0,是用編碼

34、后的數(shù)據(jù)直接解碼，沒有任何的丟失和錯(cuò)誤，解碼文件和參考文件完全相同。Encoder-conf iff Filedecoder.cffiTInput H.264bitstiaAnitest.264Outputdecoded YUU 4=2 =©test_dec SiuuOutputstatus flie»dec1 rijititire-ni：R± flie1.匕空！. _ITI：亡J'OC must-For f icIdW for SHHs to Jmscoricc tPOGQPSrirYSnHJSini-UI inc>1CI >02820204

35、43丄.583938： 006?4072CP228丄號(hào).585531.933537.95191563<P>420丄B =942531.8OG837-68421724CP>62819.077931.845338.38561875CP>82318 .926632.156738-51332356<P>IM19 VB08132.126138.379317212陰in31.475337.693S17114IS.520530.521137,263123&9CP>1628丄E291530068加.G37925010CP182817.882729 7548制E

36、534123411<P>2028丄會(huì)9372136.484425312CP>2228±7.656528.606835.557329713<P>2428丄7791829.259335-B12114CP32ft3B»795536.seal2R315<P>畫睜畫知32,37,672B265圖 3-10 PSNR 求解結(jié)果見圖 3-10所示，圖中 PSNR 為解碼后的圖像和重建圖像之間的求解值。4問題解答4.1 JM能在linux下運(yùn)行么？JM是標(biāo)準(zhǔn)的C文件，是可以在在linux系統(tǒng)里面，直接用 GCC等譯碼器直接進(jìn)行編譯運(yùn)行的，同時(shí)JM工

37、程里自帶 makefile文件，所以只需要調(diào)用 makefile進(jìn)行編譯就好了。4.2 JM編碼器對(duì)數(shù)據(jù)丟失的處理？1. JM編碼器對(duì)于數(shù)據(jù)的丟失不支持比特級(jí)錯(cuò)誤的處理，只支持對(duì)于包丟失的處理，在JM接收到數(shù)據(jù)包的丟失的時(shí)候，因?yàn)榘男蛱?hào)不連續(xù)，解碼器一旦檢測(cè)到包序號(hào)不連續(xù)就會(huì)將不連續(xù)的地方的所有宏塊的標(biāo)記ei_flag = 1，然后進(jìn)行錯(cuò)誤隱藏。2. gaps_in_frame_num_value_allowed_flag 這個(gè)句法元素等于 1時(shí)，表示允許句法元素frame_num 可以不連續(xù)。當(dāng)傳輸信道堵塞嚴(yán)重時(shí)，編碼器來不及將編碼后的圖像全部發(fā)出，這時(shí)允許丟棄若干幀圖像。在正常情況下每一幀圖像都有依次連續(xù)的frame_num值，解碼器檢查到如果 frame_num不連續(xù)，便能確定有圖像被編碼器丟棄。這時(shí)，解碼器必須啟動(dòng)錯(cuò)誤掩藏的機(jī)制來近似地恢復(fù)這些圖像，因?yàn)檫@些圖像有可能被后續(xù)圖像用作參考幀。當(dāng)這個(gè)句法元素等于 0時(shí)，表不允許frame_num不連續(xù)，即編碼器在任何情況下都不能丟棄圖像