|
論壇說明 | 標記討論區已讀 |
歡迎您來到『史萊姆論壇』 ^___^ 您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的! 請點擊這裡:『註冊成為我們的一份子!』 |
|
主題工具 | 顯示模式 |
2005-03-04, 07:08 AM | #1 |
榮譽會員
|
解釋一下以下各參數在MPG壓縮時的作用
Q:
解釋一下以下各參數在MPG壓縮時的作用 max_qdiff=3 max_b_frames=2 qcompress=0.5 mb_qmin=1 mb_qmax=31 pre_me=2 rc_eq=tex lmin=1 lmax=5 qmin=1 qmax=5 qblur=0 spatial_cplx_masking=0.3 strict_std_compliance=-1 me_pre_cmp=2 rc_qsquish=1.0 rc_buffer_aggressivity=1.0 bit_rate_tolerance=8000000 mb_decision=0 b_quant_factor=1.25 b_quant_offset=1.25 i_quant_factor=0.8 i_quant_offset=0.0 rc_strategy=2 b_frame_strategy=0 luma_elim_threshold=0 chroma_elim_threshold=0 rc_qmod_amp=0 rc_qmod_freq=0 dct_algo=0 lumi_masking=0.0 dark_masking=0.0 temporal_cplx_masking= 0.0 naq=0 prediction_method=0 me_cmp=0 pre_dia_size=0 dia_size=0 trell=0 me_range=0 intra_quant_bias=999999 inter_quant_bias=999999 coder_type=0 context_model=0 cbp=0 mv0=0 inter_threshold=0 scenechange_threshold=0 vbv=20 mpeg_quant=0 idct_algo=0 dct_algo=0 p_masking=0 me_method=4 rc_override_count=0 mb_cmp=0 me_sub_cmp=0 mb_decision=0 last_predictor_count=0 me_subpel_quality=8 rc_min_rate = 0 A: 知道的回答一些,由於很多專有的E文術語不知道有沒有準確的中文譯法,所以可能有一些描述不是很準確。 max_qdiff=3 //視瀕中所有楨(包括i/b/P)的最大Q值差距 max_b_frames=2 //兩個非B楨之間的最大B楨數目。 qcompress=0.5 //浮點數值,表示在壓制「容易壓的場景」和「難壓的場景」時,允許Q值之比值的變化範圍。可選值是0.0-1.0。 mb_qmin=1 // MicroBlock的最小Q值 mb_qmax=31 // MicroBlock的最大Q值 pre_me=2 // 提前進行運動場景預測. rc_eq=tex //選項碼率控制的方法。TEX是方法之一。 lmin=1 //最小拉格朗日乘數。拉格朗日乘數法(lagrange multipler)是用來檢定瞬間平均值的一種統計學方法。 lmax=5 //最大拉格朗日乘數 qmin=1 //Q值最小值 qmax=5 //Q值最大值. qblur=0 //浮點數,表示Q值的比例隨時間消減的程度,取之範圍是0.0-1.0,取0就是不消減。 spatial_cplx_masking=0.3 //浮點數,表示空間複雜性的masking力度。0.0-1.0 strict_std_compliance=-1 //表示嚴格遵照既定標準(MPEG4等等) me_pre_cmp=2 //運動場景預判功能的力度。數值越大編碼時間越長。 rc_qsquish=1.0 //採用Qmin/Qmax的比值來限定和控制碼率的方法。選1表示局部(即一個clip)採用此方法,選1表示全部採用。 rc_buffer_aggressivity=1.0 //浮點數. 表示開啟解碼器碼流緩衝(decoder bitstream buffer) bit_rate_tolerance=8000000 //表示有多少bit的視瀕流可以偏移出目前的設定.這裡的"設定"是指的cbr或者vbr. mb_decision=0 //Macroblock的判定模式.有3種,0表示採用用Macroblock比較,2表示採用失真率(rate distortion)參考,1表示選項0和2中碼率需求最低的一種 b_quant_factor=1.25 //表示i/p與B的Q值比例因子,值越大B楨劣化越嚴重 b_quant_offset=1.25 //表示1/p與B的Q值比例的偏移量,值越大B楨劣化越嚴重.如果大於0,那麼下一個B的Q=前一個P的Q乘以b_quant_factor再加上offset,如果小於0,則B的Q=負的normal_Q乘以factor加上offset. i_quant_factor=0.8 //p和i的Q值比例因子,越接近1則P越最佳化. i_quant_offset=0.0 //p和i的Q的偏移量 rc_strategy=2 //設定碼率控制原則. 這個原則記不得了;( b_frame_strategy=0 //B楨產生原則.(我也說不清) luma_elim_threshold=0 //消除luma(亮度,"紅樓梯")門限 chroma_elim_threshold=0 //從名字上看像是消除色度錯誤的門限,不理解. dct_algo=0 //離散餘弦變換算法設定,有7種預設定,包括: 0:FF_DCT_AUTO 1:FF_DCT_FASTINT, 2:FF_DCT_INT , 3:FF_DCT_MMX , 4:FF_DCT_MLIB, 5:FF_DCT_ALTIVEC 6:FF_DCT_FAAN 有印象好像這些與設算法是針對不同的CPU指令集作最佳化的,根據作壓制的機器CPU來選項0-6. lumi_masking=0.0 dark_masking=0.0 //這兩個表示對過亮或過暗的場景作masking的力度.0表示不作. Q: 再請教一個問題: YV12 格式的原理和資料存放規則 最好能精確到每個像素的存放位置 A: YV12格式的原理好像不太容易簡短的說清,要說到colorspace、RGB、YUV、directShow等許多東西,限於時間關係我就只能大略的說一下了。(真的要說麼……) 首先,YV12是一種colorspace(色彩空間)的小分類。我們一般的colorspace有兩種大類,就是RGB和YUV,YV12是YUV這一大類的一個小類。要說清楚它的原理,我想我們需要先瞭解到colorspace的原理。為什麼需要co lorspace呢?colorspace是記錄的圖像中各個像素(或像素塊)經過份光、放大、校正以後資料。我先舉較為簡單也較為早期的RGB這個格式來講一下。您如果已經瞭解了RGB,請跳過虛線中的這一段。 ================================================================================================ 我們知道所謂的「三基色原理「,任意一種色光F都可以用不同份量的R、G、B三色相加混合而成; 所以我們有這樣一個公式: F = r [ R ] + g [ G ] + b [ B ] 其中,r、g、b分別為三基色參與混合的係數。當三基色份量都為0(最弱)時混合結果為黑色光(實際就是沒有光);而當三基色份量都為最強時混合為白色光。根據不同的r、g、b係數的取值,就可以混合出介於黑色光和白色光之間的各種各樣的色光。 ================================================================================================ 而對於較新的YUV2,其程序是把彩色圖像信號經分色、放大、校正後得到RGB,再經過矩陣變換(或其他可替代的算法)得到亮度信號Y和兩個色差信號R-Y(即U)、B-Y(即V),最後傳送端(可能是軟體,也可能是硬體)將亮度和色差三個信號分別進行編 碼,用同一信道傳送出去。這種色彩的表示方法就是所謂的YUV色彩空間表示法。 在一般的編碼方式裡,大家有兩種RGB/YUV2的互換方法。 首先的這一種被常常運用在硬體編解碼場合下:(比如某些顯示卡晶片) Y = 0.299R + 0.587G + 0.114B U = -0.147R - 0.289G + 0.436B V = 0.615R - 0.515G - 0.100B R = Y + 1.14V G = Y - 0.39U - 0.58V B = Y + 2.03U 而在較新的視瀕壓縮算法研究中,現在已經把算法更新為:(H263首先採用了這樣的算法昇級) Y=((R×313524)>>20)+((G×615514)>>20)×((B×119538)>>20); V=((R-Y)×743962))>>20; U=((B-Y)×589244))>>20; 之所以這樣做,主要是為了加快編解碼的速度。H.263原有的色彩空間轉換算法採用浮點運算,但浮點運算會消耗較多的CPU週期。為了加快視瀕處理速度,採用整形乘法和向右移位來替代浮點乘除,從而有效縮短了轉換時間。 YUV格式的子類有好多種:YUY2、YUYV、YVYU、UYVY、AYUV、Y41P、Y411、Y211、IYUV、YV12、YVU9、YUV411、YUV420、IF09等等。您關心的YV12就是其中之一。它們正式的名字應該叫作:視瀕媒體 檔案類型輔助說明檔案類型(Subtype) YUV格式按照算法不同,分為兩大類:packed和planar。(國內的資料譯作「封裝式」和「平鋪式」) packed模式將Y、U、V份量都存放在同一個陣列中,通常是幾個相鄰的像素組成一個巨集像素(macro-pixel);而planar模式使用三個陣列分開存放Y、U、V三個份量,這可以想像成一個坐標陣列集合。YV12是planar的。 對於每個像素,YV12格式為每個像素都提取Y份量,而在提取U、V份量時,首先將圖像分成若干個2 x 2的巨集塊,然後每個巨集塊提取一個U份量和一個V份量。 假設圖像是MxN像素的,則3種份量的提取方案為: 可見只有Y份量的提取資料是一個MxN的planar,U和V都是一個(M/2)x(N/2)的planar。 順便說一下,當我們採用黑白設定壓制視瀕時,就根本沒有U和V這兩個色差信號了,只記錄Y這個亮度信號。所以當我們用相同的Q值對演員表作credit時,得到的視瀕擋案理論上的體積是不採用黑白的一半。 不知我說的這些能否對你的問題有說明 。但願你提到的像素的存放位置就是指的我上面說的採樣提取位置。如果你說的是視瀕文件中的資料游標位置,那真就不是一下講得清的,那好像要涉及到流游標、時間軸游標、iDCT(反離散餘弦)算法等等,OMG~~ 對VIDEO型的DVD,去場一直是不小的問題,解決的好不僅能大大增進VIDEO型DVDRIP的品質,而且還可以舉一反三,也適用於DV類視瀕源的去場處理. 片源:高清晰NTSC DVD(VIDEO型)720X480,29,97FPS,平均碼率在7.2MBPS. 方法一: 採用VD(MOD)原有的的BLEND去場,XVID編碼 品質Q5 BLEND是一種最長用的去場方法,速度快,去場完全,但圖像模糊,產生文件體積8.3M,比同樣XVID編碼設定的起它去場方法的文件體積小很多,可見訊息含量大打折扣. 對BLEND去場的詳細原理和算法,只知道它是取了兩場的訊息,但顯然不是簡單地平均,還請SILKY有空加以說明. 方法二: VD外掛的 SMART DEINTERLACE(2,4)去場濾鏡,預設設定MSD 20,XVID編碼 品質Q5. 速度最慢,少量的畫格局部去場不完全,產生文件體積11.3M,可見兩場的都訊息保留不少. 方法三: TMPGENC裡的ODD/EVEN去場,XVID編碼 品質Q5. 由於是只取一場的訊息,去場自然完全.最後產生文件體積10.0M. 但由於只有一場的訊息,可見物體邊緣不平滑,頭明顯的鋸齒,且細節也減少. 方法四: DIVX5原有的的去場,DIVX5編碼 品質Q5. 原理不明.但效果要好於BLEND差於SMART DEINTERLACE.最後產生文件體積10.1M. 方法五: RM9原有的的自動去場. 去場完全,由於RM9編碼的特點,細節損失很多,但物體的輪廓2還是平滑的,可見RM9的去場還是計算了兩場的訊息. 方法六: AVIUTL裡的自動去場選項,XVID編碼 品質Q5. 只是在個別畫格的局部可見到去場不完全的現象,最後產生的文件體積10.1M. AVIUYL的去場偏重一一場的訊息,所以對比強清晰讀高,但會漏掉一些細節. 是不錯的的去場方法. 方法七. VD(MOD)+AVS+DECOMB的去場,XVID編碼 品質Q5. 去場基本完全,最後剩成的文件體積10.5M. LoadPlugin("j:\avs\Decomb.dll") FieldDeinterlace(full=false) 該法的去場偏向於兩場訊息的BLEND方式,的清晰度比AVIUTL略低,但某些細節保留比AVIUTI多,某些畫格還是會見到疊影. 另:行內人士說它是盜用的SMART DEINTERLACE的算法,但結果看來青出於藍. 方法八: VD(MOD)外掛的DeinterlaceMAP濾鏡的去場,XVID編碼 品質Q5. 去場基本完全,最後剩成的文件體積11.0M. 有AVIUTL和DECOMB兩者的優點,即保留細節也保留清晰度,且沒有疊影. 目前可能排在NO.1. 美中不足的是速度比AVIUTL和DECOMB要慢一倍左右. 可以看出,YUV 4:2:0,垂直方向的彩色像素只有一半。當 progressive_frame = 1 的時候,彩色像素 Chroma 的位置是位在兩個 Luminance 亮度像素的中間。所以取樣的時候,chroma1 = (c1+c2)/2, chroma2 = (c3+c4)/2,用原本 YUV 4:4:4 的 c1 和 c2 求平均,得到位在中間的 chroma1 的值。 當 progressive_frame = 0 的時候,畫面拆成兩個 Field 取樣,Chroma 在每個 Field 不是位於正中間,而是位在 3:1 的位置上,所以取樣算式變成 chroma1 = 0.75*c1 + 0.25*c3, chroma2 = 0.25*c2 + 0.75*c4。注意交錯畫面是拿 c1 和 c3 取樣 chroma1,因為 c1 和 c3 才是屬於同一個 Field 畫面(奇數掃瞄線組成的奇數圖場),c2 和 c4 位在另一個 Field 上(偶數掃瞄線組成的偶數圖場)。而循序畫面則是拿 c1 和 c2 取樣 chroma1,兩者有很大的不同。 以前曾經有提過,現在有很多 DVD Player 有 chroma upsampling 的錯誤,那時說有機會再解釋,現在解釋。 Chroma Upsampling 錯誤就是,許多 DVD Player 不會判斷 progressive_frame 這個旗標,當遇到交錯畫面時,chroma upsampling,由 YUV 4:2:0 -> YUV 4:4:4,要用交錯畫面的 upsampling 計算式,chroma1 要分給 c1 位置和 c3 位置來使用,不可以給 c1 和 c2 使用,因為交錯畫面當初取樣時,是拿 c1, c3 算出 chroma1 的。 同理,當遇到循序畫面時,要用循序畫面的 chroma upsampling 計算式,chroma1 要分給 c1 和 c2 使用。 現在許多 DVD Player 不會分辦這個旗標,upsampling 時只有一種計算法,譬如說軟體 DVD Player 因為使用 YV12 Overlay,所以造成只能用循序畫面的計算式,遇到交錯畫面,色彩像素就會解錯,c2 會拿 chroma1 的像素來用。 這個軟體譯碼的問題也就是 DVD2AVI 的作者當初寫 DVD2AVI 這個軟體的原因,因為他受不了 Chroma 錯誤譯碼之後的畫面。想知道譯碼錯誤的畫面長什麼樣子,請看 DVD2AVI 作者網頁上的圖片和說明 http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/interlace/ 目前 PowerDVD 已經解決這個 Chroma 譯碼錯誤的問題,遇到交錯畫面先分別解出兩個 Field 的 Chroma(c1 and c3, c2 and c4),再合併成一個 Frame。由於這樣要自己先做 YUV 4:2:0 -> YUV 4:2:2,所以 PowerDVD 用的是 YUY2 Overlay。 另一個譯碼錯誤的問題,普遍發生在硬體的 DVD Player 上。硬體的 DVD player 一樣不會分辨 progressive_frame 旗標,它們只有交錯畫面的 upsampling 計算式(剛好和軟體 DVD Player 相反),所以遇到循序畫面,就會解出現錯誤誤的畫面。想知道硬體 DVD Player 譯碼錯誤的畫面長什麼樣子,請看 Home Theater HiFi 這本雜誌做的測試,裡面有詳細的解說 http://www.hometheaterhifi.com/volu...bug-4-2001.html 還有列出目前市面上,有哪些 DVD Player 已經修正這個問題 http://www.hometheaterhifi.com/volu...-2001-list.html 多有趣對不對,原來我們看了這麼久的 DVD,解碼畫面竟然不正確! 回歸原題,DVD2AVI 顯示的 Frame Type 訊息,只是根據 progressive_frame 這個旗標,代表的意義是這個 Frame 當初壓縮時,是用 Progressive Frame 取樣,還是 Interlaced Frame 取樣,和實際上畫面是否有交錯無關。 當然正確的情況下,無交錯的畫面應該用 Progressive Frame 取樣,有交錯的畫面應該用 Interlaced Frame 取樣。但是愚蠢的 DVD 製作廠商不一定會做對,譬如說 csr2000 兄提到的他那張二區日本 DVD 全部是 100% Interlaced,這個就是一個做錯的例子。這代表當初廠商在壓縮時就做錯,DVD2AVI 只是忠實反應這個錯誤。 我手上也有很多片子明明是循序畫面卻用 100% Interlaced Frame(譬如說日本二區的 Full Metal Panic NCOP),真是讓人哭笑不得。 想想這些大廠都會犯錯,連硬體 DVD Player 都會做錯,那麼壓縮時搞錯設定也就不是什麼奇怪的事情了。 以上,一樣是幫 DVD2AVI 申申冤 |
送花文章: 3,
|