menc-feat-x264.html

MPlayer-mingw32-1.0rc2.zip 经典播放器源码

  </p></li><li><p>
  <span class="bold"><strong>b_pyramid</strong></span>:
  You might as well enable this option if you are using &gt;=2 B-frames;
  as the man page says, you get a little quality improvement at no
  speed cost.
  Note that these videos cannot be read by libavcodec-based decoders
  older than about March 5, 2005.
</p></li><li><p>
  <span class="bold"><strong>weight_b</strong></span>:
  In typical cases, there is not much gain with this option.
  However, in crossfades or fade-to-black scenes, weighted
  prediction gives rather large bitrate savings.
  In MPEG-4 ASP, a fade-to-black is usually best coded as a series
  of expensive I-frames; using weighted prediction in B-frames
  makes it possible to turn at least some of these into much smaller
  B-frames.
  Encoding time cost is minimal, as no extra decisions need to be made.
  Also, contrary to what some people seem to guess, the decoder
  CPU requirements are not much affected by weighted prediction,
  all else being equal.
  </p><p>
  Unfortunately, the current adaptive B-frame decision algorithm
  has a strong tendency to avoid B-frames during fades.
  Until this changes, it may be a good idea to add
  <tt class="option">nob_adapt</tt> to your x264encopts, if you expect
  fades to have a large effect in your particular video
  clip.
  </p></li><li><p><a name="menc-feat-x264-encoding-options-speedvquality-threads"></a>
  <span class="bold"><strong>threads</strong></span>:
  This option allows to spawn threads to encode in parallel on multiple CPUs.
  You can manually select the number of threads to be created or, better, set
  <tt class="option">threads=auto</tt> and let
  <code class="systemitem">x264</code> detect how many CPUs are
  available and pick an appropriate number of threads.
  If you have a multi-processor machine, you should really consider using it
  as it can to increase encoding speed linearly with the number of CPU cores
  (about 94% per CPU core), with very little quality reduction (about 0.005dB
  for dual processor, about 0.01dB for a quad processor machine).
  </p></li></ul></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="menc-feat-x264-encoding-options-misc-preferences"></a>14.5.1.3.聽Options pertaining to miscellaneous preferences</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
  <span class="bold"><strong>Two pass encoding</strong></span>:
  Above, it was suggested to always use two pass encoding, but there
  are still reasons for not using it. For instance, if you are capturing
  live TV and encoding in realtime, you are forced to use single-pass.
  Also, one pass is obviously faster than two passes; if you use the
  exact same set of options on both passes, two pass encoding is almost
  twice as slow.
  </p><p>
  Still, there are very good reasons for using two pass encoding. For
  one thing, single pass ratecontrol is not psychic, and it often makes
  unreasonable choices because it cannot see the big picture. For example,
  suppose you have a two minute long video consisting of two distinct
  halves.  The first half is a very high-motion scene lasting 60 seconds
  which, in isolation, requires about 2500kbps in order to look decent.
  Immediately following it is a much less demanding 60-second scene
  that looks good at 300kbps. Suppose you ask for 1400kbps on the theory
  that this is enough to accomodate both scenes. Single pass ratecontrol
  will make a couple of "mistakes" in such a case. First of all, it
  will target 1400kbps in both segments. The first segment may end up
  heavily overquantized, causing it to look unacceptably and unreasonably
  blocky. The second segment will be heavily underquantized; it may look
  perfect, but the bitrate cost of that perfection will be completely
  unreasonable. What is even harder to avoid is the problem at the
  transition between the two scenes. The first seconds of the low motion
  half will be hugely over-quantized, because the ratecontrol is still
  expecting the kind of bitrate requirements it met in the first half
  of the video. This "error period" of heavily over-quantized low motion
  will look jarringly bad, and will actually use less than the 300kbps
  it would have taken to make it look decent. There are ways to
  mitigate the pitfalls of single-pass encoding, but they may tend to
  increase bitrate misprediction.
  </p><p>
  Multipass ratecontrol can offer huge advantages over a single pass.
  Using the statistics gathered from the first pass encode, the encoder
  can estimate, with reasonable accuracy, the "cost" (in bits) of
  encoding any given frame, at any given quantizer. This allows for
  a much more rational, better planned allocation of bits between the
  expensive (high-motion) and cheap (low-motion) scenes. See
  <tt class="option">qcomp</tt> below for some ideas on how to tweak this
  allocation to your liking.
  </p><p>
  Moreover, two passes need not take twice as long as one pass. You can
  tweak the options in the first pass for higher speed and lower quality.
  If you choose your options well, you can get a very fast first pass.
  The resulting quality in the second pass will be slightly lower because size
  prediction is less accurate, but the quality difference is normally much
  too small to be visible. Try, for example, adding
  <tt class="option">subq=1:frameref=1</tt> to the first pass
  <tt class="option">x264encopts</tt>. Then, on the second pass, use slower,
  higher-quality options:
  <tt class="option">subq=6:frameref=15:partitions=all:me=umh</tt>
  </p></li><li><p>
  <span class="bold"><strong>Three pass encoding</strong></span>?
  x264 offers the ability to make an arbitrary number of consecutive
  passes. If you specify <tt class="option">pass=1</tt> on the first pass,
  then use <tt class="option">pass=3</tt> on a subsequent pass, the subsequent
  pass will both read the statistics from the previous pass, and write
  its own statistics. An additional pass following this one will have
  a very good base from which to make highly accurate predictions of
  framesizes at a chosen quantizer. In practice, the overall quality
  gain from this is usually close to zero, and quite possibly a third
  pass will result in slightly worse global PSNR than the pass before
  it. In typical usage, three passes help if you get either bad bitrate
  prediction or bad looking scene transitions when using only two passes.
  This is somewhat likely to happen on extremely short clips. There are
  also a few special cases in which three (or more) passes are handy
  for advanced users, but for brevity, this guide omits discussing those
  special cases.
</p></li><li><p>
  <span class="bold"><strong>qcomp</strong></span>:
  <tt class="option">qcomp</tt> trades off the number of bits allocated
  to "expensive" high-motion versus "cheap" low-motion frames. At
  one extreme, <tt class="option">qcomp=0</tt> aims for true constant
  bitrate. Typically this would make high-motion scenes look completely
  awful, while low-motion scenes would probably look absolutely
  perfect, but would also use many times more bitrate than they
  would need in order to look merely excellent. At the other extreme,
  <tt class="option">qcomp=1</tt> achieves nearly constant quantization parameter
  (QP). Constant QP does not look bad, but most people think it is more
  reasonable to shave some bitrate off of the extremely expensive scenes
  (where the loss of quality is not as noticeable) and reallocate it to
  the scenes that are easier to encode at excellent quality.
  <tt class="option">qcomp</tt> is set to 0.6 by default, which may be slightly
  low for many peoples' taste (0.7-0.8 are also commonly used).
</p></li><li><p>
  <span class="bold"><strong>keyint</strong></span>:
  <tt class="option">keyint</tt> is solely for trading off file seekability against
  coding efficiency. By default, <tt class="option">keyint</tt> is set to 250. In
  25fps material, this guarantees the ability to seek to within 10 seconds
  precision. If you think it would be important and useful to be able to
  seek within 5 seconds of precision, set <tt class="option">keyint=125</tt>;
  this will hurt quality/bitrate slightly. If you care only about quality
  and not about seekability, you can set it to much higher values
  (understanding that there are diminishing returns which may become
  vanishingly low, or even zero). The video stream will still have seekable
  points as long as there are some scene changes.
</p></li><li><p>
  <span class="bold"><strong>deblock</strong></span>:
  This topic is going to be a bit controversial.
  </p><p>
  H.264 defines a simple deblocking procedure on I-blocks that uses
  pre-set strengths and thresholds depending on the QP of the block
  in question.
  By default, high QP blocks are filtered heavily, and low QP blocks
  are not deblocked at all.
  The pre-set strengths defined by the standard are well-chosen and
  the odds are very good that they are PSNR-optimal for whatever
  video you are trying to encode.
  The <tt class="option">deblock</tt> allow you to specify offsets to the preset
  deblocking thresholds.
  </p><p>
  Many people seem to think it is a good idea to lower the deblocking
  filter strength by large amounts (say, -3).
  This is however almost never a good idea, and in most cases,
  people who are doing this do not understand very well how
  deblocking works by default.
  </p><p>
  The first and most important thing to know about the in-loop
  deblocking filter is that the default thresholds are almost always
  PSNR-optimal.
  In the rare cases that they are not optimal, the ideal offset is
  plus or minus 1.
  Adjusting deblocking parameters by a larger amount is almost
  guaranteed to hurt PSNR.
  Strengthening the filter will smear more details; weakening the
  filter will increase the appearance of blockiness.
  </p><p>
  It is definitely a bad idea to lower the deblocking thresholds if
  your source is mainly low in spacial complexity (i.e., not a lot
  of detail or noise).
  The in-loop filter does a rather excellent job of concealing
  the artifacts that occur.
  If the source is high in spacial complexity, however, artifacts
  are less noticeable.
  This is because the ringing tends to look like detail or noise.
  Human visual perception easily notices when detail is removed,
  but it does not so easily notice when the noise is wrongly
  represented.
  When it comes to subjective quality, noise and detail are somewhat
  interchangeable.
  By lowering the deblocking filter strength, you are most likely
  increasing error by adding ringing artifacts, but the eye does
  not notice because it confuses the artifacts with detail.
  </p><p>
  This <span class="bold"><strong>still</strong></span> does not justify
  lowering the deblocking filter strength, however.
  You can generally get better quality noise from postprocessing.
  If your H.264 encodes look too blurry or smeared, try playing with
  <tt class="option">-vf noise</tt> when you play your encoded movie.
  <tt class="option">-vf noise=8a:4a</tt> should conceal most mild
  artifacting.
  It will almost certainly look better than the results you
  would have gotten just by fiddling with the deblocking filter.
  </p></li></ul></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="menc-feat-x264-example-settings"></a>14.5.2.聽Encoding setting examples</h3></div></div></div><p>
The following settings are examples of different encoding
option combinations that affect the speed vs quality tradeoff
at the same target bitrate.
</p><p>
All the encoding settings were tested on a 720x448 @30000/1001 fps
video sample, the target bitrate was 900kbps, and the machine was an
AMD-64 3400+ at 2400 MHz in 64 bits mode.
Each encoding setting features the measured encoding speed (in
frames per second) and the PSNR loss (in dB) compared to the "very
high quality" setting.
Please understand that depending on your source, your machine type
and development advancements, you may get very different results.
</p><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><thead><tr><th>Description</th><th>Encoding options</th><th>speed (in fps)</th><th>Relative PSNR loss (in dB)</th></tr></thead><tbody><tr><td>Very high quality</td><td><tt class="option">subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b</tt></td><td>6fps</td><td>0dB</td></tr><tr><td>High quality</td><td><tt class="option">subq=5:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</tt></td><td>13fps</td><td>-0.89dB</td></tr><tr><td>Fast</td><td><tt class="option">subq=4:bframes=2:b_pyramid:weight_b</tt></td><td>17fps</td><td>-1.48dB</td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="menc-feat-xvid.html">Prev</a>聽</td><td width="20%" align="center"><a accesskey="u" href="encoding-guide.html">Up</a></td><td width="40%" align="right">聽<a accesskey="n" href="menc-feat-video-for-windows.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">14.4.聽Encoding with the <code class="systemitem">Xvid</code>
  codec聽</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">聽14.6.聽
  Encoding with the <code class="systemitem">Video For Windows</code>
  codec family
</td></tr></table></div></body></html>