史萊姆論壇

返回   史萊姆論壇 > 教學文件資料庫 > 應用軟體使用技術文件
忘記密碼?
註冊帳號 論壇說明 標記討論區已讀

歡迎您來到『史萊姆論壇』 ^___^

您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的!

請點擊這裡:『註冊成為我們的一份子!』

Google 提供的廣告


 
 
主題工具 顯示模式
舊 2005-03-04, 07:08 AM   #1
psac
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設 解釋一下以下各參數在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種份量的提取方案為:
http://img20.exs.cx/img20/6599/yvideo24rz.jpg

http://img20.exs.cx/img20/9567/uvideo8av.jpg

可見只有Y份量的提取資料是一個MxN的planar,U和V都是一個(M/2)x(N/2)的planar。

順便說一下,當我們採用黑白設定壓制視瀕時,就根本沒有U和V這兩個色差信號了,只記錄Y這個亮度信號。所以當我們用相同的Q值對演員表作credit時,得到的視瀕擋案理論上的體積是不採用黑白的一半。

不知我說的這些能否對你的問題有說明 。但願你提到的像素的存放位置就是指的我上面說的採樣提取位置。如果你說的是視瀕文件中的資料游標位置,那真就不是一下講得清的,那好像要涉及到流游標、時間軸游標、iDCT(反離散餘弦)算法等等,OMG~~

http://img20.exs.cx/img20/3839/video229vd.jpg

對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 申申冤
psac 目前離線  
送花文章: 3, 收花文章: 1630 篇, 收花: 3204 次
 


主題工具
顯示模式

發表規則
不可以發文
不可以回覆主題
不可以上傳附加檔案
不可以編輯您的文章

論壇啟用 BB 語法
論壇啟用 表情符號
論壇啟用 [IMG] 語法
論壇禁用 HTML 語法
Trackbacks are 禁用
Pingbacks are 禁用
Refbacks are 禁用


所有時間均為台北時間。現在的時間是 10:38 AM


Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2020, Jelsoft Enterprises Ltd.


SEO by vBSEO 3.6.1