“X264設定”的版本间的差异
小 |
（→幀類型選項） |
||
| 第62行： | 第62行： | ||
'''預設：250''' | '''預設：250''' | ||
設定x264的輸出中最大的IDR幀（亦稱關鍵幀）間隔。可以指定"infinite"讓x264永遠不要插入 | 設定x264的輸出中最大的IDR幀（亦稱關鍵幀）間隔。可以指定"infinite"讓x264永遠不要插入 非場景變換 的IDR幀。 | ||
IDR幀是視頻流的“分隔符號”，所有幀都不可以從IDR幀的另一邊參考資料。因此，IDR幀也是I幀，所以它們不從任何其他幀參考資料。這意味著它們可以用作視頻的搜尋點（seek points）。 | IDR幀是視頻流的“分隔符號”，所有幀都不可以從IDR幀的另一邊參考資料。因此，IDR幀也是I幀，所以它們不從任何其他幀參考資料。這意味著它們可以用作視頻的搜尋點（seek points）。 | ||
| 第77行： | 第77行： | ||
設定IDR幀之間的最小長度。 | 設定IDR幀之間的最小長度。 | ||
對於IDR幀的說明可參閱{{x|keyint}}。過小的keyint範圍可能會導致“錯誤的”IDR幀 | 對於IDR幀的說明可參閱{{x|keyint}}。過小的keyint範圍可能會導致“錯誤的”IDR幀 放 置（例如閃屏場景）。此選項限制了在每個IDR幀之後，要有多少幀才能再有另一個IDR幀的最小長度。 | ||
min-keyint的最大允許值為{{x|keyint}}/2+1。 | min-keyint的最大允許值為{{x|keyint}}/2+1。 | ||
| 第91行： | 第91行： | ||
'''參閱：'''{{x|scenecut}} | '''參閱：'''{{x|scenecut}} | ||
===scenecut=== | |||
'''預設：40''' | |||
設定放置I/IDR幀的閾值（場景變換偵測）。 | |||
x264為每一幀計算它與前一幀不同程度的度量值。如果該值低於scenecut，則算偵測到一個“場景變換”。如果此時與最近一個IDR幀的距離低於{{x|min-keyint}}則放置一個I幀，否則放置一個IDR幀。越高的scenecut值會增加場景變換偵測到的數量。場景變換是如何比較的詳細資訊可參閱[http://forum.doom9.org/showthread.php?t=121116 http://forum.doom9.org/showthread.php?t=121116]。 | |||
將scenecut設為0等同於設{{x|no-scenecut}}。 | |||
'''建議：'''預設值 | |||
'''參閱：'''{{x|keyint}}, {{x|min-keyint}}, {{x|no-scenecut}} | |||
===intra-refresh=== | |||
'''預設：無''' | |||
停用IDR幀，作為替代x264會為每隔{{x|keyint}}的幀的每個宏塊使用內部編碼（intra coding）。塊是以一個水平捲動的行刷新，叫做刷新波（refresh wave）。這有利於低延遲的流，使它有可能比標準的IDR幀達到更加恆定的幀尺寸。這也增強了視頻流對封包遺失的恢復能力。此選項會降低壓縮效率，因此有需要時才用。 | |||
有趣的事： | |||
* 第一幀仍然是IDR幀 | |||
* 內部塊（Intra-blocks）僅處於P幀中，刷新波在一或多個B幀後的第一個P幀更廣泛 | |||
* The loss in compression efficiency comes primarily from the fact macroblocks on the 'new' (left) side of the refresh wave can't refer to data on the 'old' (right) side. | |||
2010年11月24日 (三) 14:00的版本
本頁說明所有x264參數之目的和用法。參數的排列相同於在x264 --fullhelp出現的順序。
x264設定
說明
x264帶有一些內置的文件。要閱讀此說明，執行x264 --help、x264 --longhelp或x264 --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。
建議：預設值，或者等於幀率
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的幀的每個宏塊使用內部編碼（intra coding）。塊是以一個水平捲動的行刷新，叫做刷新波（refresh wave）。這有利於低延遲的流，使它有可能比標準的IDR幀達到更加恆定的幀尺寸。這也增強了視頻流對封包遺失的恢復能力。此選項會降低壓縮效率，因此有需要時才用。
有趣的事：
- 第一幀仍然是IDR幀
- 內部塊（Intra-blocks）僅處於P幀中，刷新波在一或多個B幀後的第一個P幀更廣泛
- The loss in compression efficiency comes primarily from the fact macroblocks on the 'new' (left) side of the refresh wave can't refer to data on the 'old' (right) side.