史萊姆論壇

返回   史萊姆論壇 > 教學文件資料庫 > 資訊系統安全備援防護技術文件
忘記密碼?
論壇說明 標記討論區已讀

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

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

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

Google 提供的廣告


 
 
主題工具 顯示模式
舊 2005-03-22, 12:07 PM   #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 金幣
預設 教學 - H.264--保證清晰視瀕的尖端武器

H.264/AVC 越來越熱門了,偶也來關心一下,轉個文章看看。

H.264--保證清晰視瀕的尖端武器 作者:山大聯潤訊息科技有限公司 文章來源:IT168


如果您對比使用過視維和其他品牌的視瀕會議產品,您會發現,在相同的網路條件下,使用相同的機器,視維產品的視瀕清晰度和流暢度要遠遠高於其他產品,視維是如何解決「視瀕品質」和「網路帶寬佔用」這個矛盾的呢?

在視瀕會議套用中,視瀕品質和網路帶寬佔用是矛盾的,通常情況下視瀕流佔用的帶寬越高則視瀕品質也越高;如要求高品質的視瀕效果,那麼需要的網路帶寬也越大;解決這一矛盾的鑰匙當然是視瀕編解碼技術。評判一種視瀕編解碼技術的優劣,是比較在相同的帶寬條件 下,哪個視瀕品質更好;在相同的視瀕品質條件下,哪個佔用的網路帶寬更少。

視瀕編解碼技術有兩套標準,國際電聯(ITU-T)的標準H.261、H.263、H.263+等;還有ISO 的MPEG標準Mpeg1、Mpeg2、Mpeg4等等。H.264/AVC是兩大組織集合H.263+和Mpeg4的優點聯合推出的最新標準,最具價值的部分無疑是更高的資料壓縮比。在同等的圖像品質條件下,H.264的資料壓縮比能比H.263高2倍,比MPEG-4高1.5倍。

以下我們簡單介紹H.264的概念和發展,並探討H.264技術實用化的可能性。

H.264/AVC是什麼?
H.264/AVC標準是由ITU-T和ISO/IEC聯合開發的,定位於覆蓋整個視瀕套用領域,包括:低碼率的無線套用、標準清晰度和高清晰度的電視廣播套用、Internet上的視瀕流套用,傳輸高清晰度的DVD視瀕以及套用於數位相機的高品質視瀕套用等等。

ITU-T給這個標準命名為H.264(以前叫做H.26L),而ISO/IEC稱它為MPEG-4 進階視瀕編碼(Advanced Video Coding,AVC),並且它將成為MPEG-4標準的第10部分。既然AVC是當前MPEG-4標準的拓展,那麼它必然將受益於MPEG-4開發良好的基礎結構(比如系統分層和音瀕等)。很明顯,作為MPEG-4進階簡潔框架(Advanced Simple Profile,ASP)的MPEG-4 AVC將會優於現用的MPEG-4視瀕壓縮標準,它將主要套用在具有高度壓縮率和分層次品質需求的方向。

就像在下邊「視瀕編碼歷史」表格中看到的,ITU-T和ISO/IEC負責以前所有的國際視瀕壓縮標準的設定。到目前為止,最成功的視瀕標準是MPEG-2,它已經被各種市場領域所廣泛接受比如DVD、數位電視廣播(覆蓋電纜和通訊衛星)和數位機上盒。自從MPEG-2技術產生以來,新的H.264/MPEG-4 AVC標準在編碼效率和品質上有了巨大的提高。隨著時間的過去,在許多現有的套用領域,H.264/MPEG-4 AVC將會取代MPEG-2和MPEG-4,包括一些新興的市場(比如ADSL視瀕)。

數位視瀕編解碼技術的演變

國際標準通常是由國際標準化組織ISO在國際電信聯盟 ITU的技術建議的基礎上制訂的。數位視瀕編解碼標準也經歷了多次變革,其演變工作如圖所顯示:


很明顯,H264標準使運動圖像壓縮技術上升到了一個更高的階段,在較低帶寬上提供高品質的圖像傳輸是H.264的套用亮點。H.264的推廣套用對視瀕終端、網守、網路閘道、MCU等系統的要求較高,將有力地推動視瀕會議軟設備在各個方面的不斷完善。

H.264的核心競爭力
H.264最具價值的部分無疑是更高的資料壓縮比。壓縮技術的基本原理就是將視瀕文件中的非重要訊息過濾,以便讓資料能夠更快地在網路中傳輸。在同等的圖像品質條件下,H.264的資料壓縮比能比當前DVD系統中使用的MPEG-2高2-3倍,比MPEG-4高1.5-2倍。正因為如此,經過H.264壓縮的視瀕資料,在網路傳輸程序中所需要的帶寬更少,也更加經濟。

在MPEG-4需要6Mbps的傳輸速率匹配時,H.264只需要3Mbps-4Mbps的傳輸速率。我們用交通運輸來做更加形象的比喻:同樣是用一輛卡車運輸一個大箱子,假如MPEG-4能把箱子減重一半,那麼H.264能把箱子減重為原來的1/4,在卡車載重量不變的情況下,H.264比MPEG-2讓卡車的載貨量增加了二倍。

H.264獲得優越效能的代價是計算複雜度的大幅增加,例如分層設計、多畫格參論、多模式運動估計、改進的畫格內預測等,這些都顯著提高了預測精度,從而獲得比其他標準好得多的壓縮效能。

不斷提高的硬體處理能力和不斷最佳化的軟體算法是H.264得以風行的生存基礎。早在十年前,主頻為幾十兆的CPU就達到了頂級,而如今普通的桌上型,CPU的主頻已經高達幾千兆。按照摩爾定律的說法,晶片服務機構面積的容量每18個月翻一番,因此H.264所 增加的運算複雜度相對於效能提升效果而言微不足道。更何況新的計算方法層出不窮,也相對緩解H.264對處理速度的飢渴需求。

H.264 與MPEG-4的比較

1、在極低碼率(32-128Kbps)的情況下,H.264與MPEG-4相比具有效能倍增效應,即: 相同碼率的H.26L媒體流和MPEG-4媒體流相比,H.26L擁有大約3個分貝的增益(畫質水準倍增)。 32Kbps的H.26L媒體流,其信躁比與128K的MPEG-4媒體流相近。即在同樣的畫面品質下,H.264的碼率僅僅為MPEG-4的四分之一。



2、 H.26L在中低碼率下與MPEG-4比較: 在中低碼率(32-128Kbps)的情況下,H.26L與MPEG-4相比具有效能倍增效應。


H.264標準推出僅一年,大部分宣傳支持H.264的終端廠商主要都是支持H.264的基本等級。因為H.264編解碼複雜度的增加,對終端廠商的視瀕處理能力提出了挑戰。現有的平台,要麼就根本無法做H.264的編解碼,要麼就不能支持高碼率下的編解 碼。而視維視瀕會議產品最大支持640*480,視瀕標準採用最新的高碼率編解碼技術,圖像清晰流暢。在帶寬節約39%的基礎上視瀕品質的信噪比要比同類產品高出40%,是目前視瀕品質最好的編碼技術。


H.264/AVC核心技術概覽

就像在圖中看到的一樣,這個新的標準是由下面幾個處理步驟組成的:

畫格間和畫格內預測
變換(和反變換)
量化(和反量化)
環路濾波
熵編碼

單張的圖片流組成了視瀕,它能分成16X16像素的「巨集塊」,這種分塊方法簡化了在視瀕壓縮算法中每個步驟的處理程序。舉例來說,從標準清晰度標準視瀕流解決方案(720X480)中截取的一幅圖片被分成1350(45X30)個巨集塊,然後在巨集塊的層次進 行進一步的處理。

畫格間預測

改良的運動估計。運動估計用來確定和消除存在於視瀕流中不同圖片之間的時間冗余。當運動估計搜尋是根據過去方向的圖片,那麼被編碼的圖片稱為「P畫格圖片」,當搜尋是根據過去和將來兩種方向的圖片,那麼被編碼的圖片被稱為「B畫格圖片」。

為了提高編碼效率,為了包含和分離在「H.264運動估計-改良的運動估計」圖中的運動巨集塊,巨集塊被拆分成更小的塊。然後,以前或將來的圖片的運動向量被用來預測一個給定的塊。H.264/MPEG-4 AVC發明了一種更小的塊,它具有更好的靈活性,在運動向量方面可以有更高的預測精度。

H.264運動估計-改良的運動估計

畫格內預測

不能運用運動估計的地方,就採用畫格內估計用來消除空間冗余。內部估計通過在一個預定義好的集合中不同方向上的接近塊推測相鄰像素來預測當前塊。然後預測塊和真實塊之間的不同點被編碼。這種方法是H.264/MPEG-4 AVC所特有的,尤其對於經常存在空間冗余的平坦背景特別有用。一個例子就是下邊展示的「H.264內部估計」。

H.264內部估計

變換

運動估計和內部估計後的結果通過變換被從空間域轉換到頻率域。H.264/MPEG-4 AVC使用整數DCT4X4變換。而MPEG-2和MPEG-4使用浮點DCT8X8變換。

更小塊的H.264/MPEG-4 AVC減少了塊效應和明顯的人工痕跡。整數係數消除了在MPEG-2和MPEG-4中進行浮點係數運算時導致的精度損失。

H.264變換

量化

變換後的係數被量化,減少了整數係數的預測量和消除了不容易被感知高頻係數。這個步驟也用來控制輸出的比特率維持在一個基本恆定的常量。

H.264量化/碼率控制

環路濾波

H.264/MPEG-4 AVC標準定義了一個對16X16巨集塊和4X4塊邊界的解塊過濾程序。在巨集塊這種情況下,過濾的目的是消除由於相鄰巨集塊有不同的運動估計檔案類型(比如運動估計和內部估計)或者不同的量化參數導致的人工痕跡。在塊邊界這種情況下,過濾的目的是消除可能由於變換 /量化和來自於相鄰塊運動向量的差別引起的人工痕跡。環路濾波通過一個內容自適應的非線性算法修改在巨集塊/塊邊界的同一邊的兩個像素。

熵編碼

在熵編碼之前,4X4的量化係數必須被重排序。根據這些係數原來採用的預測算法為運動估計或者內部估計的不同來選項不同的掃瞄檔案類型新增一個重排序的串行化流。掃瞄檔案類型按照從低頻到高頻的順序排序這些係數。既然高頻係數大多數趨向於零,那麼利用游程編碼就可 以縮減零的數目,從而高效的達到熵編碼的目的。

H.264熵編碼-係數的串行化

在熵編碼步驟通過映射符號的字元流來表示運動向量,量化係數和巨集塊頭。熵編碼通過設計用一個較少的比特位數來表示頻繁使用的符號,比較多的比特位數來表示不經常使用的符號。


H.264雖然具有如此優秀的特點,但是標準算法卻需要耗費巨大的系統資源,硬體視瀕會議昇級到H.264的困難在於此,原有的晶片無法支持如此大量的運算;軟體視瀕會議系統昇級到H.264的困難也在於此,普通PC的處理能力無法滿足編碼H.264的要 求。
psac 目前離線  
送花文章: 3, 收花文章: 1630 篇, 收花: 3204 次
有 2 位會員向 psac 送花:
cythilya (2009-05-26),wulihua (2006-09-25)
感謝您發表一篇好文章
舊 2005-03-22, 09:55 PM   #2 (permalink)
yohem
榮譽勳章

勳章總數
UID -
在線等級:
文章: n/a
精華:
預設

謝謝大大如此詳盡的解說
 
送花文章: 0, 收花文章: 0 篇, 收花: 0 次
舊 2006-09-23, 03:33 AM   #3 (permalink)
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設

使用H264編碼壓制HDTVrip的方法說明(附圖)
自從新的CoreAVC解碼器出現後,H264編碼的HDTV就變得不是那麼高不可攀拉,更多的機器可以流暢播放這種可以提供更好畫質的編碼影片。考慮使用最簡單的方法獲得H264壓縮的方法,初步探索如下:
Gordian Knot 是一款不錯的影音編輯軟件,也是本人常用的壓片軟件。
(使用方法參考
http://www.silu.info/read.php?tid=42798&fpage=1
但是本身好像不帶H264編碼器,所以先安裝H264編碼器「SE_H264編碼器」(附件見後,解壓後右鍵點擊x264vfw.inf選安裝)



http://www.silu.info/1124728446/Type_jpg/210_37053_c469ef465730e90.jpg

在使用Gordian Knot壓片時選擇x264編碼


http://www.silu.info/1124728446/Type_jpg/210_37053_85b1b989eed1fe5.jpg

壓片時使用兩次編碼:

http://www.silu.info/1124728446/Type_jpg/210_37053_ede1af0598e6360.jpg

第二遍時可以控制碼率,預定壓制的最大值有時並不止5000


http://www.silu.info/1124728446/Type_jpg/210_37053_43a1e6096ecf0dd.jpg



至於一般1280X720的片子碼率在4000~5000畫質就相當滿意了,再大CPU負擔太重。
以x264和H264在本質上是一樣的,使H264的子集,使用MeGUI感覺比GK好用點,碼率計算後自動填入設置。
各位如果要嘗試H.264編碼的話很多家的中,推薦Mainconcept的H.264編碼器,個人我覺得這個比較成熟,且功能也很完善.
如果用的是普通的x264,可以自動計算碼率
版本太老了!往http://x264.nl/可下傳新版
其實壓出好的x264,方法很多,我試過nero recode,TMPGEnc3XP,都不錯。相對TMPGEnc3XP呼叫x264編碼器比nero快些。關鍵是x264的編碼設置,B-frames參數,Max consecutive (0-16),使用avi容器建議關閉。這樣播放更流暢一些。
要是能在編碼設置上多研究,比較,大家探討就更好了。

x264 vfw版用avi輸出是有b-frame的問題,不過用VirtualDubMod的話也可以用MKV輸出。對於壓制一些小東西還是很方便的(寫AVS還是有點麻煩),而且最新版的VFW又新增了幾個CLI版的參數。CLI版對於製作DVDrip或HDRE是最好的選擇,CLI版壓置高質量的作品時推薦大家加入ROD-6/NO fast P-ship/JVT matrix這幾個參數,能明顯的改善畫面中的"塊"現象。

為什麼 avc 不該再用 vfw-avi:
http://forum.doom9.org/showthread.php?s=&threadid=80430
http://forum.doom9.org/showthread.php?t=99061

理想的方法是用 cli (通過 megui 協助或直接用 cli) 直接輸出 mp4/mkv, 兩者都有原生的 avc/h.264 支援

請勿再用 x264-vfw, vfw 比 cli 少了的功能:
http://forum.doom9.org/showthread.php?t=105899

avc/h.264 用 vfw/avi 的壞處:

QUOTE:
[轉]目前不同的AVC 工具支持不同的容器(Container):
.mp4:mp4 是MPGE-4 標準(ISO 14496-15)指定的AVC 容器。目前支持它的編碼器有Nero、Sorenson、Envivio 和Moonlight。
.mpg:mpg 是MPEG-2 標準(ISO 13818-1,AMD3)指定的AVC 容器。目前支持它的編碼器有:Mainconcept 和Moonlight。(藍光BD-ROM 也會使用這種容器,具體請參見http://www.blu-ray.com)
.avi:使用AVI 作為容器是不標準的,並且會造成不相容的問題。使用AVI 可能妨礙AVC 的一些功能的發揮,也可能會損傷回放的質量,或者降低解碼速度。目前支持avi 的編碼器有VSS、x264(mencoder 和x264 的vfw 都支持)、mpegable。
.264/.h264:通常是參考編碼器輸出的作為例子的源圖像。(mencoder 中的x264 也可以輸出.264,mp4creator 可以從.mp4 種Demux 出來)

@zy88810
Nero Recode 用的是 Nero Digital (Mpeg-4 ASP 級) 和 Nero AVC, 事實上最新的應該是由子公司 Ateme 開發的 Ateme AVC, 不清楚是否已經整合入 Nero Recode, 但 Nero 絕對和 X264 沒關係, 我上面貼的 doom9 比較 (http://www.doom9.org/index.html?/codecs-final-105-1.htm ) 也說明了這點
至於 TMPGEnc3XP 則不清楚, 或者用的都是 vfw 介面, 還是有上面的問題

>x264 vfw版用avi輸出是有b-frame的問題
vfw/avi 用 bframe 本來就有問題, 不單是 avc 獨有, 上面貼的 http://forum.doom9.org/showthread.php?s=&threadid=80430
說明了這點

>不過用VirtualDubMod的話也可以用MKV輸出
vdubm 和 vdub 一樣都是以 vfw 為基礎的, 用 vdubm 的 mkv 輸出其實就等於做成 avi 再以 vfw 模式 mux 入 mkv, 它不過是一步完成
這和 x264 cli 或 mencoder 直接輸出的原生 avc-mkv (native avc mkv) 是不一樣的, 而 vfw 模式 avc-mkv 和 avc-avi 是一樣的, 有上面的問題, 我上面貼的最後一個連結 (http://forum.doom9.org/showthread.php?t=99061 ) 說的就是這個

>而且最新版的VFW又新增了幾個CLI版的參數
呵呵, 那簡直是個惡耗, 據說 x264 的開發者本來有意完全放棄 vfw 的, 不過說到尾 vfw 的功能始終沒有 cli 的完整

>JVT matrix
測試中好像只有一個 cqm 在低碼率中比預設的好, 而且不是 jvt, 用預設就好了



JVT matrix 我說的是用在高質量的作品,也就是說高碼率的dvdrip或hdre。但由於同Q值下JVT matrix 會大幅增加文件容量(我測試的片斷中增加了30%多,如果配合ROD-6的話只增加了10%.當然質量也有所下降,但如果是用2-PASS輸出同樣大小的文件的話應當是較好的選擇)

ROD-6是不如ROD-7更有壓縮率,但是比ROD-7快很多。對於製作dvdrip和hdre來說能節約很多的時間。如果不在乎時間的話ROD-7是更好。

發幾個圖比比看預定matrix同JVT matrix的區別給大家看看,源是dvd,為了方便觀察圖像都放大到了1024。參數如下:
Starting job job1 at 11:18:27
Job is a video job. encoder commandline:
--qp 20 --keyint 240 --min-keyint 6 --no-fast-pskip --bframes 1 --b-rdo --bime --weightb --subme 6 --analyse all --8x8dct --direct spatial --progress --no-psnr --output "E:\3.mp4" "E:\3.avs"
successfully started encoding
Processing ended at 11:19:20
----------------------------------------------------------------------------------------------------------

Log for job job1

avis [info]: 720x288 @ 23.98 fps (553 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
mp4 [info]: initial delay 417083 (scale 10000000)
x264 [info]: slice I:24 Avg QP:17.00 size: 10982
x264 [info]: slice P:378 Avg QP:20.00 size: 4477
x264 [info]: slice B:151 Avg QP:22.00 size: 2054
x264 [info]: mb I I16..4: 49.0% 38.2% 12.8%
x264 [info]: mb P I16..4: 13.3% 19.3% 2.9% P16..4: 23.5% 4.6% 1.5% 0.2% 0.1% skip:34.6%
x264 [info]: mb B I16..4: 0.7% 2.2% 0.7% B16..8: 23.4% 1.5% 2.2% direct: 2.1% skip:67.2%
x264 [info]: 8x8 transform intra:52.1% inter:45.8%
x264 [info]: kb/s:786.0

Actual bitrate after encoding without container overhead: 786.47
This is a CQ job so there's no desired bitrate. Obtained video bitrate: 788.349640894153 kbit/s
----------------------------------------------------------------------------------------------------------
Starting job job2 at 11:22:34
Job is a video job. encoder commandline:
--qp 20 --keyint 240 --min-keyint 6 --no-fast-pskip --bframes 1 --b-rdo --bime --weightb --subme 6 --analyse all --8x8dct --direct spatial --cqm "jvt" --progress --no-psnr --output "E:\4.mp4" "E:\3.avs"
successfully started encoding
Processing ended at 11:23:31
----------------------------------------------------------------------------------------------------------

Log for job job2

avis [info]: 720x288 @ 23.98 fps (553 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
mp4 [info]: initial delay 417083 (scale 10000000)
x264 [info]: slice I:25 Avg QP:17.00 size: 12098
x264 [info]: slice P:377 Avg QP:20.00 size: 5086
x264 [info]: slice B:151 Avg QP:22.00 size: 2012
x264 [info]: mb I I16..4: 23.4% 71.4% 5.2%
x264 [info]: mb P I16..4: 3.2% 19.9% 1.0% P16..4: 44.6% 7.0% 2.4% 0.2% 0.1% skip:21.8%
x264 [info]: mb B I16..4: 0.1% 1.6% 0.3% B16..8: 22.2% 1.6% 2.5% direct: 1.9% skip:69.8%
x264 [info]: 8x8 transform intra:80.2% inter:71.6%
x264 [info]: kb/s:875.4

Actual bitrate after encoding without container overhead: 875.85
This is a CQ job so there's no desired bitrate. Obtained video bitrate: 877.682730085177 kbit/s
----------------------------------------------------------------------------------------------------------
Starting job job3 at 11:24:15
Job is a video job. encoder commandline:
--qp 20 --keyint 240 --min-keyint 6 --no-fast-pskip --bframes 1 --bime --weightb --analyse all --8x8dct --direct spatial --cqm "jvt" --progress --no-psnr --output "E:\5.mp4" "E:\3.avs"
successfully started encoding
Processing ended at 11:24:56
----------------------------------------------------------------------------------------------------------

Log for job job3

avis [info]: 720x288 @ 23.98 fps (553 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
mp4 [info]: initial delay 417083 (scale 10000000)
x264 [info]: slice I:34 Avg QP:17.00 size: 11886
x264 [info]: slice P:368 Avg QP:20.00 size: 6231
x264 [info]: slice B:151 Avg QP:22.00 size: 2278
x264 [info]: mb I I16..4: 39.8% 44.8% 15.4%
x264 [info]: mb P I16..4: 24.7% 20.8% 5.7% P16..4: 21.6% 5.6% 2.0% 0.6% 0.4% skip:18.5%
x264 [info]: mb B I16..4: 0.7% 2.0% 1.7% B16..8: 15.5% 1.2% 2.9% direct: 4.9% skip:71.1%
x264 [info]: 8x8 transform intra:41.4% inter:23.1%
x264 [info]: kb/s:1054.8

Actual bitrate after encoding without container overhead: 1055.33
This is a CQ job so there's no desired bitrate. Obtained video bitrate: 1057.12620051311 kbit/s

建議不要用x264的vfw版壓
把AVS直接扔給MeGUI用x264CLI壓
vfw的壓縮質量不如CLI

vfw版的x264是比較好用的,當時出到388版時,作者曾表示放棄繼續更新,但是今年元月份就又推出了新版的408版,說明,他還是有發展前途的,畢竟比較好用,但就實際輸出問題,就比較複雜了,首先,封裝問題,採用avi和mkv封裝,都有問題,avi在播放時有問題,相容性很差,一拖動,就需要很長時間才能正常滿幀播放,mkv封裝,用gk呼叫vdm封裝的mkv,自己也打不開,不太明白其中道理。

再說cli版的x264,首先軟件要求環境比較複雜,研究很長時間才知道啟動megui所需環境(充分說明本人比較菜),等測試結束後封裝mkv時,發現很多軟件不識別?!(本人對視頻瞭解很少),視頻倒是能播放,另外,它的相容性比較差,如果原始視頻中有一點什莫問題,就會中途退出,本人編寫的avs文件,很多都不識別退出,可能是對avs還沒有研究透,播放到沒有看到有什莫問題,這兩種編碼器出來的片子,都播放正常,效果也都差不多。

上班後還沒有在進行深入研究,目前還採用vfw版的x264進行編碼,用vdm或avi_mux gui封裝mkv,doom9出的cli版的還沒有詳細研究,看著他們在春節中還是401版的,現在已經到439版了,更新速度突飛猛進,我還是先等等再用的說。

本人e文較差,doom9上面的看不了全意,歡迎大家多多指導,爭取能多為大家貢獻好片子。
裝好x264的code,在vdm裡就可以選擇使用264,而且選項也多很多呢.GK覺得太死板了



圖片:
http://www.silu.info/1124728446/Type_jpg/210_2287_9d1c3aaca3d70df.jpg

http://www.silu.info/1124728446/Type_jpg/205_2287_d4f13f74d47e979.jpg
回:yanyani989
Nero Recode 的確不是呼叫的x264,是他自帶的AVC編碼,也是屬於H264的吧。我沒有說清楚。我用的是nero7 裡的。編碼速度比x264慢。
TMPGEnc3XP是呼叫的x264。界面如圖


mencoder -priority belownormal -nosound -noskip -oac copy -ovc x264 -x264encopts pass=1:turbo=1:qp_constant=26:keyint=250:keyint_min=5:subq=6:me=2:4x4mv:8x8dct:frameref=5:bframes=3:b_pyramid:weight_b:brdo -of rawvideo %1 -o %2.h264 -passlogfile %2.static

mencoder -priority belownormal -nosound -noskip -oac copy -ovc x264 -x264encopts pass=2:bitrate=800:qp_constant=26:keyint=250:keyint_min=5:subq=6:me=4:4x4mv:8x8dct:frameref=5:bframes=3:b_pyramid:weight_b:brdo -of rawvideo %1 -o %2.h264 -passlogfile %2.static

這個我的twopass的
我輸出raw,然後用
mp4box %2.mp4 -add %2.h264
合成mp4

聲音在用mkvgui合成mkv
壓x264最好不要用碼率,要習慣量化器,用QP和CRF來配合



KoanH264視頻編碼器 V1.0怎麼樣?

ZT軟件介紹

H264 — 蘋果公司聲稱的下一代MPEG標準,將應用於手機及高清晰度領域,能以有效的低資料流量傳輸。

  本軟件的主要功能就是使用H264編碼製作高清AVI文件,可以對主流的視頻格式進行轉換,軟件內置H264的獨立編解碼功能,直接製作H264文件,編解碼視頻文件時無需系統Direct Show Filter支持,支持截取VCD任一聲道,安裝軟件的同時系統也能夠支持播放H264文件。

  軟件採用最為簡潔,直觀的界面設計,適合各個階段的電腦用戶使用,並且最適合初級用戶使用。
  
  軟件通過優化CPU指令,並且預定使用空閒級的優先級,使得編碼的同時可以流暢地進行其它操作,不會大量地佔用系統資源。

軟件支持的格式:avi,rm,rmvb,wmv,mpg,dat,vob,asf,dv,mp4,mkv,ogm,ts(HDV)

KoanH264 高階視頻編碼器 安裝包說明:直接雙擊安裝即可使用

**********************************************************************
  本軟件的主要功能是使用H264編碼製作高清AVI文件,可以對主流的視頻格式進行轉換,包括avi,rm,rmvb,wmv,mpg,dat,vob,asf,dv,mp4,mkv,ogm,ts等,本軟件內置H264的獨立編解碼功能,直接製作H264文件,編解碼視頻文件時無需系統Direct Show Filter支持,支持截取VCD任一聲道,安裝軟件的同時系統也能夠支持播放H264文件。

  當前版本是1.0傻瓜版,正式發佈於2006年9月15日,適合初級電腦用戶使用,專業版將於近期內推出,適合專業視頻製作用戶使用,軟件支持 Windows 98/NT/2K/XP/2003 系統
__________________
http://bbsimg.qianlong.com/upload/01/08/29/68/1082968_1136014649812.gif
psac 目前離線  
送花文章: 3, 收花文章: 1630 篇, 收花: 3204 次
向 psac 送花的會員:
chungying999 (2008-08-02)
感謝您發表一篇好文章
 


主題工具
顯示模式

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

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


所有時間均為台北時間。現在的時間是 03:52 PM


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


SEO by vBSEO 3.6.1