“X264設定”的版本间的差异

来自NMM Doc
跳到导航 跳到搜索
第6行: 第6行:


==輸入==
==輸入==
  一個位置參數指定輸入的視頻。例如:
  一個位置參數指定輸入的視頻。例如:
  x264.exe -o NUL C:\input.avs
  x264.exe -o NUL C:\input.avs
  x264 -o /dev/null ~/input.y4m
  x264 -o /dev/null ~/input.y4m
 當輸入的視頻是raw YUV格式時,還必須告訴x264視頻的解析度。你可能也要用{{x|fps}}來指定幀率:
 當輸入的視頻是raw YUV格式時,還必須告訴x264視頻的解析度。你可能也要 使 用{{x|fps}}來指定幀率:
  x264.exe -o NUL --fps 25 --input-res 1280x720 D:\input.yuv 
  x264.exe -o NUL --fps 25 --input-res 1280x720 D:\input.yuv 
  x264 -o /dev/null --fps 30000/1001 --input-res 640x480 ~/input.yuv
  x264 -o /dev/null --fps 30000/1001 --input-res 640x480 ~/input.yuv


==預設值系統==
==預設值系統==
 為減少使用者花費時間和精神在命令列上而設計的一套系統。這些設定切換了哪些選項可從<code>x264 --fullhelp</code>的說明中得知。
 為 減少使用者花費時間和精神在命令列上而設計的一套系統。這些設定切換了哪些選項可 從<code>x264 --fullhelp</code>的說明中得知。


===profile===
===profile===
第54行: 第54行:
* {{x|trellis}}<code> 0</code>
* {{x|trellis}}<code> 0</code>


 可以設{{x|slow-firstpass}}來停用此特性。使用{{x|preset}}<code> placebo</code>也會啟用slow-firstpass。
 可以設{{x|slow-firstpass}}來停用此特性。 注意, 使用{{x|preset}}<code> placebo</code>也會啟用slow-firstpass。


'''參閱:'''{{x|pass}}
'''參閱:'''{{x|pass}}
第66行: 第66行:
IDR幀是流的“分隔符號”,所有幀都不能從IDR幀的另一邊參考資料。因此,IDR幀也是I幀,所以它們不從任何其他幀參考資料。這意味著它們可以用作視頻的搜尋點(seek points)。
IDR幀是流的“分隔符號”,所有幀都不能從IDR幀的另一邊參考資料。因此,IDR幀也是I幀,所以它們不從任何其他幀參考資料。這意味著它們可以用作視頻的搜尋點(seek points)。


  注意,I幀通常明顯大於P/B幀(在低運動場景通常為10倍大或更多),所以當它們與極低的VBV設定合併使用時會打亂碼率控制。在這些情況下,研究{{x|intra-refresh}}。
 注意,I幀通常明顯大於P/B幀(在低運動場景通常為10倍大或更多),所以當它們與極低的VBV設定合併使用時會打亂碼率控制。在這些情況下,研究{{x|intra-refresh}}。


 預設值對於大多數視頻沒啥問題。在為藍光、廣播、直播流或某些其他特殊情況編碼時,可能需要更小的GOP長度(通常等於幀率)。
 預設值對於大多數視頻沒啥問題。在為藍光、廣播、直播流或某些其他特殊情況編碼時,可能需要更小的GOP長度(通常等於幀率)。
第108行: 第108行:
'''預設:無'''
'''預設:無'''


 停用IDR幀,作為替代x264會為每隔{{x|keyint}}的幀的每個宏塊(macroblock)使用內部編碼(intra coding)。塊是以一個水平捲動的行刷新,稱為刷新波(refresh wave)。這有利於低延遲的流,使它有可能比標準的IDR幀達到更加恆定的幀 尺寸 。這也增強了視頻流對封包遺失的恢復能力。此選項會降低壓縮效率,因此必要時才使用。
 停用IDR幀,作為替代x264會為每隔{{x|keyint}}的幀的每個宏塊(macroblock)使用內部編碼(intra coding)。塊是以一個水平捲動的行刷新,稱為刷新波(refresh wave)。這有利於低延遲的流,使它有可能比標準的IDR幀達到更加恆定的幀 大小 。這也增強了視頻流對封包遺失的恢復能力。此選項會降低壓縮效率,因此必要時才使用。


 有趣的事:
 有趣的事:
第122行: 第122行:
 沒有B幀時,一個典型的x264流有著像這樣的幀類型:IPPPPP...PI。當設了<code>--bframes 2</code>時,最多兩個連續的P幀可以被B幀取代,就像:IBPBBPBPPPB...PI。
 沒有B幀時,一個典型的x264流有著像這樣的幀類型:IPPPPP...PI。當設了<code>--bframes 2</code>時,最多兩個連續的P幀可以被B幀取代,就像:IBPBBPBPPPB...PI。


B幀類似於P幀,只是B幀還能從它之後的幀做動作預測(motion prediction)。就壓縮比來說效率會 顯著 提高。它們的平均品質是由{{x|pbratio}}所控制。
B幀類似於P幀,只是B幀還能從它之後的幀做動作預測(motion prediction)。就壓縮比來說效率會 大幅 提高。它們的平均品質是由{{x|pbratio}}所控制。


 有趣的事:
 有趣的事:
* x264還區分兩種不同種類的B幀。"B"是代表一個被其他幀 用來 作為參考的B幀(參閱{{x|b-pyramid}}),而"b"則代表一個不被其他幀 用來 作為參考的B幀。如果看到一段混合的"B"和"b",原因通常與上述有關。當差別並不重要時,通常就以"B"代表所有B幀。
* x264還區分兩種不同種類的B幀。"B"是代表一個被其他幀作為參考 的B幀(參閱{{x|b-pyramid}}),而"b"則代表一個不被其他幀作為參考 的B幀。如果看到一段混合的"B"和"b",原因通常與上述有關。當差別並不重要時,通常就以"B"代表所有B幀。
* x264是如何為每個候選幀選定為P幀或B幀的詳細資訊可以參閱[http://article.gmane.org/gmane.comp.video.ffmpeg.devel/29064 http://article.gmane.org/gmane.comp.video.ffmpeg.devel/29064]。在此情況下,幀類型將如下所示(假設<code>--bframes 3</code>):IBBBPBBBPBPI。
* x264是如何為每個候選幀選定為P幀或B幀的詳細資訊可以參閱[http://article.gmane.org/gmane.comp.video.ffmpeg.devel/29064 http://article.gmane.org/gmane.comp.video.ffmpeg.devel/29064]。在此情況下,幀類型將如下所示(假設<code>--bframes 3</code>):IBBBPBBBPBPI。


第137行: 第137行:
:<code>0</code>:停用自適應,總是選取B幀。這與舊的<code>no-b-adapt</code>相同作用。
:<code>0</code>:停用自適應,總是選取B幀。這與舊的<code>no-b-adapt</code>相同作用。


:<code>1</code>:“快速”演算法,較快,越高的{{x|bframes}}會稍微 增加 速度。在使用此模式時,基本上建議使用{{x|bframes}}<code> 16</code>。
:<code>1</code>:“快速”演算法,較快,越高的{{x|bframes}}會稍微 提高 速度。在使用此模式時,基本上建議使用{{x|bframes}}<code> 16</code>。


:<code>2</code>:“最佳”演算法,較慢,越高的{{x|bframes}}會 明顯 降低速度。
:<code>2</code>:“最佳”演算法,較慢,越高的{{x|bframes}}會 大幅 降低速度。


 注意:對於多趟(multi-pass)編碼,僅在第一趟(first pass)才需要此選項,因為幀類型在此時已經判定完了。
 注意:對於多趟(multi-pass)編碼,僅在第一趟(first pass)才需要此選項,因為幀類型在此時已經判定完了。
第146行: 第146行:
'''預設:0'''
'''預設:0'''


 控制B幀被用來代替P幀的可能性。大於0的值增加偏向B幀的加權,而小於0的值則相反。此數是個隨意自定的度量值。範圍是從-100到100。100並不保證全 是B 幀(要使用{{x|b-adapt}}<code> 0</code>),而-100也不保證全 是P 幀。
 控制B幀被用來代替P幀的可能性。大於0的值增加偏向B幀的加權,而小於0的值則相反。此數是 個隨意自定的度量值。範圍是從-100到100。100並不保證全 為B 幀(要 全為B幀該 使用{{x|b-adapt}}<code> 0</code>),而-100也不保證全 為P 幀。


 僅在你認為你能比x264做出更好的碼率控制決策時才使用此選項。
 僅在你認為你能比x264做出更好的碼率控制決策時才使用此選項。
第168行: 第168行:
'''預設:none'''
'''預設:none'''


Open-GOP 是一個提高效率的編碼技術。有三種模式:
open-gop 是一個提高效率的編碼技術。有三種模式:
:<code>none</code>:停 用Open-GOP
:<code>none</code>:停 用open-gop
:<code>normal</code>:啟 用Open-GOP
:<code>normal</code>:啟 用open-gop
:<code>bluray</code>:啟 用Open-GOP 。一個效率較低 的Open-GOP 版本,因為<code>normal</code>模式無法用於藍光編碼。
:<code>bluray</code>:啟 用open-gop 。一個效率較低 的open-gop 版本,因為<code>normal</code>模式無法用於藍光編碼。


Some decoders don't fully support open-GOP streams, which is why this hasn't been enabled by default. You should test with all decoders your streams will be played on, or (if that's impossible) wait until support is generally available.
某些解碼器不完全支援open-gop流,這就是為什麼此選項並未預設為啟用。如果想啟用open-gop,應該先測試所有可能用來撥放的解碼器。


Open-GOP 的說明可以參閱[http://forum.doom9.org/showthread.php?p=1300124#post1300124 http://forum.doom9.org/showthread.php?p=1300124#post1300124]。
open-gop 的說明可以參閱[http://forum.doom9.org/showthread.php?p=1300124#post1300124 http://forum.doom9.org/showthread.php?p=1300124#post1300124]。
 
===no-cabac===
'''預設:無'''
 
停用CABAC('''C'''ontext '''A'''daptive '''B'''inary '''A'''rithmetic '''C'''oder)壓縮,切換回效率較低的CAVLC('''C'''ontext '''A'''daptive '''V'''ariable '''L'''ength '''C'''oder)系統。大大降低了壓縮效率(通常是10~20%)和解碼的需求。
 
===ref===
'''預設:3'''
 
控制DPB('''D'''ecoded '''P'''icture '''B'''uffer)的大小。範圍是從0到16。總之,此值是每個P幀可以使用它前面多少個幀作為參考幀的數目(B幀可以使用的數目要少一或兩個,取決於它們是否作為參考幀)。可以作為參考幀的最小ref數目是1。
 
還要注意的是,H.264規格限制了每個level的DPB大小。如果遵守[http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels Level 4.1]規格,720p和1080p視頻的最大ref數分別為9和4。
 
'''參閱:'''{{x|b-pyramid}}, {{x|no-mixed-refs}}, {{x|level}}

2010年11月28日 (日) 16:58的版本

本頁說明所有x264參數之目的和用法。參數的排列相同於在x264 --fullhelp出現的順序。

x264設定

說明

x264帶有一些內置的文件。要閱讀此說明,執行x264 --helpx264 --longhelpx264 --fullhelp。越後面的選項將提供更詳細的資訊。

輸入

以一個位置參數指定輸入的視頻。例如:

x264.exe -o NUL C:\input.avs
x264 -o /dev/null ~/input.y4m

當輸入的視頻是raw YUV格式時,還必須告訴x264視頻的解析度。你可能也要使用--fps來指定幀率:

x264.exe -o NUL --fps 25 --input-res 1280x720 D:\input.yuv 
x264 -o /dev/null --fps 30000/1001 --input-res 640x480 ~/input.yuv

預設值系統

為了減少使用者花費時間和精神在命令列上而設計的一套系統。這些設定切換了哪些選項可以從x264 --fullhelp的說明中得知。

profile

預設:無

限制輸出流的profile。如果指定了profile,將覆蓋所有其他設定。所以如果指定了profile,將保證輸出的流與該profile相容。如果設了此選項,將不能使用無損編碼(--qp 0--crf 0)。

如果知道你的播放設備僅支援某個profile,則應設此選項。大多數解碼器支援High profile,因此不需要設此選項。

可用的值:baseline, main, high

preset

預設:medium

更改選項,以權衡壓縮效率和編碼速度。如果指定了preset,更改的選項將在所有其他參數套用前被套用。

通常應將此選項設為你所能承受的最慢的值。

可用的值:ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo

tune

預設:無

調整選項,以進一步優化為視頻的內容。如果指定了tune,更改的選項將在--preset之後,但所有其他參數之前被套用。

如果視頻內容符合其中一個可用的值,則可設此選項,否則就不要指定。

可用的值:film, animation, grain, stillimage, psnr, ssim, fastdecode, zerolatency

slow-firstpass

預設:無

隨著預設值系統在r1177版本的出現,使用--pass 1會在解析命令列的最後套用以下設定:

可以設--slow-firstpass來停用此特性。注意,使用--preset placebo也會啟用slow-firstpass。

參閱:--pass

幀類型選項

keyint

預設:250

設定x264輸出的流之最大IDR幀(亦稱關鍵幀)間隔。可以指定infinite讓x264永遠不要插入非場景變換的IDR幀。

IDR幀是流的“分隔符號”,所有幀都不能從IDR幀的另一邊參考資料。因此,IDR幀也是I幀,所以它們不從任何其他幀參考資料。這意味著它們可以用作視頻的搜尋點(seek points)。

注意,I幀通常明顯大於P/B幀(在低運動場景通常為10倍大或更多),所以當它們與極低的VBV設定合併使用時會打亂碼率控制。在這些情況下,研究--intra-refresh

預設值對於大多數視頻沒啥問題。在為藍光、廣播、直播流或某些其他特殊情況編碼時,可能需要更小的GOP長度(通常等於幀率)。

參閱:--min-keyint, --scenecut, --intra-refresh

min-keyint

預設:自動 (MIN(--keyint/10, --fps))

設定IDR幀之間的最小長度。

IDR幀的說明可以參閱--keyint。過小的keyint範圍可能會導致“錯誤的”IDR幀放置(例如閃屏場景)。此選項限制在每個IDR幀之後,要有多少幀才可以再有另一個IDR幀的最小長度。

min-keyint的最大允許值為--keyint/2+1。

建議:預設值,或者等於幀率

參閱:--keyint, --scenecut

no-scenecut

預設:無

完全停用自適應I幀判定。

參閱:--scenecut

scenecut

預設:40

設定放置I/IDR幀的閾值(場景變換偵測)。

x264為每一幀計算它與前一幀不同程度的度量值。如果該值低於scenecut,則算偵測到一個“場景變換”。如果此時與最近一個IDR幀的距離低於--min-keyint則放置一個I幀,否則放置一個IDR幀。越高的scenecut值會增加場景變換偵測到的數目。場景變換是如何比較的詳細資訊可以參閱http://forum.doom9.org/showthread.php?t=121116

將scenecut設為0等同於--no-scenecut

建議:預設值

參閱:--keyint, --min-keyint, --no-scenecut

intra-refresh

預設:無

停用IDR幀,作為替代x264會為每隔--keyint的幀的每個宏塊(macroblock)使用內部編碼(intra coding)。塊是以一個水平捲動的行刷新,稱為刷新波(refresh wave)。這有利於低延遲的流,使它有可能比標準的IDR幀達到更加恆定的幀大小。這也增強了視頻流對封包遺失的恢復能力。此選項會降低壓縮效率,因此必要時才使用。

有趣的事:

  • 第一幀仍然是IDR幀。
  • 內部塊(Intra-blocks)僅處於P幀中,刷新波在一或多個B幀後的第一個P幀更廣泛。
  • 壓縮效率的損失主要來自於在刷新波上左側(新)的宏塊不能參考右側(舊)的資料。

bframes

預設:3

設定x264可以使用的最大並行B幀數。

沒有B幀時,一個典型的x264流有著像這樣的幀類型:IPPPPP...PI。當設了--bframes 2時,最多兩個連續的P幀可以被B幀取代,就像:IBPBBPBPPPB...PI。

B幀類似於P幀,只是B幀還能從它之後的幀做動作預測(motion prediction)。就壓縮比來說效率會大幅提高。它們的平均品質是由--pbratio所控制。

有趣的事:

  • x264還區分兩種不同種類的B幀。"B"是代表一個被其他幀作為參考幀的B幀(參閱--b-pyramid),而"b"則代表一個不被其他幀作為參考幀的B幀。如果看到一段混合的"B"和"b",原因通常與上述有關。當差別並不重要時,通常就以"B"代表所有B幀。
  • x264是如何為每個候選幀選定為P幀或B幀的詳細資訊可以參閱http://article.gmane.org/gmane.comp.video.ffmpeg.devel/29064。在此情況下,幀類型將如下所示(假設--bframes 3):IBBBPBBBPBPI。

參閱:--b-bias, --b-pyramid, --ref, --pbratio, --partitions, --weightb

b-adapt

預設:1

設定自適應B幀放置判定演算法。此設定控制x264如何判定要放置P幀或B幀。

0:停用自適應,總是選取B幀。這與舊的no-b-adapt相同作用。
1:“快速”演算法,較快,越高的--bframes會稍微提高速度。在使用此模式時,基本上建議使用--bframes 16
2:“最佳”演算法,較慢,越高的--bframes會大幅降低速度。

注意:對於多趟(multi-pass)編碼,僅在第一趟(first pass)才需要此選項,因為幀類型在此時已經判定完了。

b-bias

預設:0

控制B幀被用來代替P幀的可能性。大於0的值增加偏向B幀的加權,而小於0的值則相反。此數是一個隨意自定的度量值。範圍是從-100到100。100並不保證全為B幀(要全為B幀該使用--b-adapt 0),而-100也不保證全為P幀。

僅在你認為你能比x264做出更好的碼率控制決策時才使用此選項。

參閱:--bframes, --ipratio

b-pyramid

預設:normal

允許B幀作為其他幀的參考幀。沒有此設定時,幀只能參考I/P幀。雖然I/P幀因其較高的品質作為參考幀更有價值,但B幀也是很有用的。作為參考幀的B幀將得到一個介於P幀和普通B幀之間的量化值。--bframes至少須設為2才會讓b-pyramid生效。

如果是在為藍光編碼,須使用nonestrict

none:不允許B幀作為參考幀。
strict:每個minigop允許一個B幀作為參考幀,這是藍光標準強制執行的限制。
normal:每個minigop允許多個B幀作為參考幀。

參閱:--bframes, --refs, --no-mixed-refs

open-gop

預設:none

open-gop是一個提高效率的編碼技術。有三種模式:

none:停用open-gop。
normal:啟用open-gop。
bluray:啟用open-gop。一個效率較低的open-gop版本,因為normal模式無法用於藍光編碼。

某些解碼器不完全支援open-gop流,這就是為什麼此選項並未預設為啟用。如果想啟用open-gop,應該先測試所有可能用來撥放的解碼器。

open-gop的說明可以參閱http://forum.doom9.org/showthread.php?p=1300124#post1300124

no-cabac

預設:無

停用CABAC(Context Adaptive Binary Arithmetic Coder)壓縮,切換回效率較低的CAVLC(Context Adaptive Variable Length Coder)系統。大大降低了壓縮效率(通常是10~20%)和解碼的需求。

ref

預設:3

控制DPB(Decoded Picture Buffer)的大小。範圍是從0到16。總之,此值是每個P幀可以使用它前面多少個幀作為參考幀的數目(B幀可以使用的數目要少一或兩個,取決於它們是否作為參考幀)。可以作為參考幀的最小ref數目是1。

還要注意的是,H.264規格限制了每個level的DPB大小。如果遵守Level 4.1規格,720p和1080p視頻的最大ref數分別為9和4。

參閱:--b-pyramid, --no-mixed-refs, --level