⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 menc-feat-x264.html

📁 MPlayer-mingw32-1.0rc2.zip 经典播放器源码
💻 HTML
📖 第 1 页 / 共 2 页
字号:
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><title>14.5.聽Encoding with the x264 codec</title><link rel="stylesheet" href="default.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.73.2"><link rel="start" href="index.html" title="MPlayer - The Movie Player"><link rel="up" href="encoding-guide.html" title="Chapter聽14.聽Encoding with MEncoder"><link rel="prev" href="menc-feat-xvid.html" title="14.4.聽Encoding with the Xvid codec"><link rel="next" href="menc-feat-video-for-windows.html" title="14.6.聽 Encoding with the Video For Windows codec family"><link rel="preface" href="howtoread.html" title="How to read this documentation"><link rel="chapter" href="intro.html" title="Chapter聽1.聽Introduction"><link rel="chapter" href="install.html" title="Chapter聽2.聽Installation"><link rel="chapter" href="usage.html" title="Chapter聽3.聽Usage"><link rel="chapter" href="cd-dvd.html" title="Chapter聽4.聽CD/DVD usage"><link rel="chapter" href="faq.html" title="Chapter聽5.聽Frequently Asked Questions"><link rel="chapter" href="containers.html" title="Chapter聽6.聽Containers"><link rel="chapter" href="codecs.html" title="Chapter聽7.聽Codecs"><link rel="chapter" href="video.html" title="Chapter聽8.聽Video output devices"><link rel="chapter" href="audio.html" title="Chapter聽9.聽Audio output devices"><link rel="chapter" href="tv.html" title="Chapter聽10.聽TV"><link rel="chapter" href="radio.html" title="Chapter聽11.聽Radio"><link rel="chapter" href="ports.html" title="Chapter聽12.聽Ports"><link rel="chapter" href="mencoder.html" title="Chapter聽13.聽Basic usage of MEncoder"><link rel="chapter" href="encoding-guide.html" title="Chapter聽14.聽Encoding with MEncoder"><link rel="appendix" href="bugreports.html" title="Appendix聽A.聽How to report bugs"><link rel="appendix" href="bugs.html" title="Appendix聽B.聽Known bugs"><link rel="appendix" href="skin.html" title="Appendix聽C.聽MPlayer skin format"><link rel="appendix" href="history.html" title="Appendix聽D.聽History"><link rel="subsection" href="menc-feat-x264.html#menc-feat-x264-encoding-options" title="14.5.1.聽Encoding options of x264"><link rel="subsection" href="menc-feat-x264.html#menc-feat-x264-example-settings" title="14.5.2.聽Encoding setting examples"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">14.5.聽Encoding with the
  <code class="systemitem">x264</code> codec</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="menc-feat-xvid.html">Prev</a>聽</td><th width="60%" align="center">Chapter聽14.聽Encoding with <span class="application">MEncoder</span></th><td width="20%" align="right">聽<a accesskey="n" href="menc-feat-video-for-windows.html">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="menc-feat-x264"></a>14.5.聽Encoding with the
  <code class="systemitem">x264</code> codec</h2></div></div></div><p>
<code class="systemitem">x264</code> is a free library for
encoding H.264/AVC video streams.
Before starting to encode, you need to
<a class="link" href="video-codecs.html#codec-x264-encode" title="7.1.3.4.聽How can I encode videos using MEncoder and x264?">set up <span class="application">MEncoder</span> to support it</a>.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="menc-feat-x264-encoding-options"></a>14.5.1.聽Encoding options of x264</h3></div></div></div><p>
Please begin by reviewing the
<code class="systemitem">x264</code> section of
<span class="application">MPlayer</span>'s man page.
This section is intended to be a supplement to the man page.
Here you will find quick hints about which options are most
likely to interest most people. The man page is more terse,
but also more exhaustive, and it sometimes offers much better
technical detail.
</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="menc-feat-x264-encoding-options-intro"></a>14.5.1.1.聽Introduction</h4></div></div></div><p>
This guide considers two major categories of encoding options:
</p><div class="orderedlist"><ol type="1"><li><p>
  Options which mainly trade off encoding time vs. quality
</p></li><li><p>
  Options which may be useful for fulfilling various personal
  preferences and special requirements
</p></li></ol></div><p>
Ultimately, only you can decide which options are best for your
purposes. The decision for the first class of options is the simplest:
you only have to decide whether you think the quality differences
justify the speed differences. For the second class of options,
preferences may be far more subjective, and more factors may be
involved. Note that some of the "personal preferences and special
requirements" options can still have large impacts on speed or quality,
but that is not what they are primarily useful for. A couple of the
"personal preference" options may even cause changes that look better
to some people, but look worse to others.
</p><p>
Before continuing, you need to understand that this guide uses only one
quality metric: global PSNR.
For a brief explanation of what PSNR is, see
<a class="ulink" href="http://en.wikipedia.org/wiki/PSNR" target="_top">the Wikipedia article on PSNR</a>.
Global PSNR is the last PSNR number reported when you include
the <tt class="option">psnr</tt> option in <tt class="option">x264encopts</tt>.
Any time you read a claim about PSNR, one of the assumptions
behind the claim is that equal bitrates are used.
</p><p>
Nearly all of this guide's comments assume you are using two pass.
When comparing options, there are two major reasons for using
two pass encoding.
First, using two pass often gains around 1dB PSNR, which is a
very big difference.
Secondly, testing options by doing direct quality comparisons
with one pass encodes introduces a major confounding
factor: bitrate often varies significantly with each encode.
It is not always easy to tell whether quality changes are due
mainly to changed options, or if they mostly reflect essentially
random differences in the achieved bitrate.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="menc-feat-x264-encoding-options-speedvquality"></a>14.5.1.2.聽Options which primarily affect speed and quality</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
  <span class="bold"><strong>subq</strong></span>:
  Of the options which allow you to trade off speed for quality,
  <tt class="option">subq</tt> and <tt class="option">frameref</tt> (see below) are usually
  by far the most important.
  If you are interested in tweaking either speed or quality, these
  are the first options you should consider.
  On the speed dimension, the <tt class="option">frameref</tt> and
  <tt class="option">subq</tt> options interact with each other fairly
  strongly.
  Experience shows that, with one reference frame,
  <tt class="option">subq=5</tt> (the default setting) takes about 35% more time than
  <tt class="option">subq=1</tt>.
  With 6 reference frames, the penalty grows to over 60%.
  <tt class="option">subq</tt>'s effect on PSNR seems fairly constant
  regardless of the number of reference frames.
  Typically, <tt class="option">subq=5</tt> achieves 0.2-0.5 dB higher global
  PSNR in comparison <tt class="option">subq=1</tt>.
  This is usually enough to be visible.
  </p><p>
  <tt class="option">subq=6</tt> is slower and yields better quality at a reasonable
  cost.
  In comparison to <tt class="option">subq=5</tt>, it usually gains 0.1-0.4 dB
  global PSNR with speed costs varying from 25%-100%.
  Unlike other levels of <tt class="option">subq</tt>, the behavior of
  <tt class="option">subq=6</tt> does not depend much on <tt class="option">frameref</tt>
  and <tt class="option">me</tt>.  Instead, the effectiveness of <tt class="option">subq=6
  </tt> depends mostly upon the number of B-frames used. In normal
  usage, this means <tt class="option">subq=6</tt> has a large impact on both speed
  and quality in complex, high motion scenes, but it may not have much effect
  in low-motion scenes. Note that it is still recommended to always set
  <tt class="option">bframes</tt> to something other than zero (see below).
  </p><p>
  <tt class="option">subq=7</tt> is the slowest, highest quality mode.
  In comparison to <tt class="option">subq=6</tt>, it usually gains 0.01-0.05 dB
  global PSNR with speed costs varying from 15%-33%.
  Since the tradeoff encoding time vs. quality is quite low, you should
  only use it if you are after every bit saving and if encoding time is
  not an issue.
  </p></li><li><p>
  <span class="bold"><strong>frameref</strong></span>:
  <tt class="option">frameref</tt> is set to 1 by default, but this
  should not be taken to imply that it is reasonable to set it to 1.
  Merely raising <tt class="option">frameref</tt> to 2 gains around
  0.15dB PSNR with a 5-10% speed penalty; this seems like a good tradeoff.
  <tt class="option">frameref=3</tt> gains around 0.25dB PSNR over
  <tt class="option">frameref=1</tt>, which should be a visible difference.
  <tt class="option">frameref=3</tt> is around 15% slower than
  <tt class="option">frameref=1</tt>.
  Unfortunately, diminishing returns set in rapidly.
  <tt class="option">frameref=6</tt> can be expected to gain only
  0.05-0.1 dB over <tt class="option">frameref=3</tt> at an additional
  15% speed penalty.
  Above <tt class="option">frameref=6</tt>, the quality gains are
  usually very small (although you should keep in mind throughout
  this whole discussion that it can vary quite a lot depending on your source).
  In a fairly typical case, <tt class="option">frameref=12</tt>
  will improve global PSNR by a tiny 0.02dB over
  <tt class="option">frameref=6</tt>, at a speed cost of 15%-20%.
  At such high <tt class="option">frameref</tt> values, the only really
  good thing that can be said is that increasing it even further will
  almost certainly never <span class="bold"><strong>harm</strong></span>
  PSNR, but the additional quality benefits are barely even
  measurable, let alone perceptible.
  </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note:</h3><p>
  Raising <tt class="option">frameref</tt> to unnecessarily high values
  <span class="bold"><strong>can</strong></span> and
  <span class="bold"><strong>usually does</strong></span>
  hurt coding efficiency if you turn CABAC off.
  With CABAC on (the default behavior), the possibility of setting
  <tt class="option">frameref</tt> "too high" currently seems too remote
  to even worry about, and in the future, optimizations may remove
  the possibility altogether.
  </p></div><p>
  If you care about speed, a reasonable compromise is to use low
  <tt class="option">subq</tt> and <tt class="option">frameref</tt> values on
  the first pass, and then raise them on the second pass.
  Typically, this has a negligible negative effect on the final
  quality: You will probably lose well under 0.1dB PSNR, which
  should be much too small of a difference to see.
  However, different values of <tt class="option">frameref</tt> can
  occasionally affect frametype decision.
  Most likely, these are rare outlying cases, but if you want to
  be pretty sure, consider whether your video has either
  fullscreen repetitive flashing patterns or very large temporary
  occlusions which might force an I-frame.
  Adjust the first-pass <tt class="option">frameref</tt> so it is large
  enough to contain the duration of the flashing cycle (or occlusion).
  For example, if the scene flashes back and forth between two images
  over a duration of three frames, set the first pass
  <tt class="option">frameref</tt> to 3 or higher.
  This issue is probably extremely rare in live action video material,
  but it does sometimes come up in video game captures.
  </p></li><li><p>
  <span class="bold"><strong>me</strong></span>:
  This option is for choosing the motion estimation search method.
  Altering this option provides a straightforward quality-vs-speed
  tradeoff. <tt class="option">me=dia</tt> is only a few percent faster than
  the default search, at a cost of under 0.1dB global PSNR. The 
  default setting (<tt class="option">me=hex</tt>) is a reasonable tradeoff
  between speed and quality. <tt class="option">me=umh</tt> gains a little under
  0.1dB global PSNR, with a speed penalty that varies depending on
  <tt class="option">frameref</tt>.  At high values of
  <tt class="option">frameref</tt> (e.g. 12 or so), <tt class="option">me=umh</tt>
  is about 40% slower than the default <tt class="option"> me=hex</tt>. With
  <tt class="option">frameref=3</tt>, the speed penalty incurred drops to
  25%-30%.
  </p><p>
  <tt class="option">me=esa</tt> uses an exhaustive search that is too slow for
  practical use.
  </p></li><li><p>
  <span class="bold"><strong>partitions=all</strong></span>:
  This option enables the use of 8x4, 4x8 and 4x4 subpartitions in
  predicted macroblocks (in addition to the default partitions).
  Enabling it results in a fairly consistent
  10%-15% loss of speed. This option is rather useless in source
  containing only low motion, however in some high-motion source,
  particularly source with lots of small moving objects, gains of
  about 0.1dB can be expected.
</p></li><li><p>
  <span class="bold"><strong>bframes</strong></span>:
  If you are used to encoding with other codecs, you may have found
  that B-frames are not always useful.
  In H.264, this has changed: there are new techniques and block
  types that are possible in B-frames.
  Usually, even a naive B-frame choice algorithm can have a
  significant PSNR benefit.
  It is interesting to note that using B-frames usually speeds up
  the second pass somewhat, and may also speed up a single
  pass encode if adaptive B-frame decision is turned off.
  </p><p>
  With adaptive B-frame decision turned off
  (<tt class="option">x264encopts</tt>'s <tt class="option">nob_adapt</tt>),
  the optimal value for this setting is usually no more than
  <tt class="option">bframes=1</tt>, or else high-motion scenes can suffer.
  With adaptive B-frame decision on (the default behavior), it is
  safe to use higher values; the encoder will reduce the use of
  B-frames in scenes where they would hurt compression.
  The encoder rarely chooses to use more than 3 or 4 B-frames;
  setting this option any higher will have little effect.
  </p></li><li><p>
  <span class="bold"><strong>b_adapt</strong></span>:
  Note: This is on by default.
  </p><p>
  With this option enabled, the encoder will use a reasonably fast
  decision process to reduce the number of B-frames used in scenes that
  might not benefit from them as much.
  You can use <tt class="option">b_bias</tt> to tweak how B-frame-happy
  the encoder is.
  The speed penalty of adaptive B-frames is currently rather modest,
  but so is the potential quality gain.
  It usually does not hurt, however.
  Note that this only affects speed and frametype decision on the
  first pass.
  <tt class="option">b_adapt</tt> and <tt class="option">b_bias</tt> have no
  effect on subsequent passes.

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -