comparison DOCS/xml/en/encoding-guide.xml @ 20254:beca75a03355

Update x264 option names that changed with r20060

20253:05ff3ca951b2

<listitem><para>
  <emphasis role="bold">me</emphasis>:
  This option is for choosing the motion estimation search method.
  Altering this option provides a straightforward quality-vs-speed
  tradeoff. <option>me=1</option> is only a few percent faster than
  the default search, at a cost of under 0.1dB global PSNR. The 
  default setting (<option>me=2</option>) is a reasonable tradeoff
  between speed and quality. <option>me=3</option> gains a little under
  0.1dB global PSNR, with a speed penalty that varies depending on
  <option>frameref</option>.  At high values of
  <option>frameref</option> (e.g. 12 or so), <option>me=3</option>
  is about 40% slower than the default <option> me=2</option>. With
  <option>frameref=3</option>, the speed penalty incurred drops to
  25%-30%.
</para>
<para>
  <option>me=4</option> uses an exhaustive search that is too slow for
  practical use.
</para>
</listitem>

<listitem><para>
  <emphasis role="bold">4x4mv</emphasis>:
  This option enables the use of 8x4, 4x8 and 4x4 subpartitions in
  predicted macroblocks. 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

  prediction is less accurate, but the quality difference is normally much
  too small to be visible. Try, for example, adding
  <option>subq=1:frameref=1</option> to the first pass
  <option>x264encopts</option>. Then, on the second pass, use slower,
  higher-quality options:
  <option>subq=6:frameref=15:4x4mv:me=3</option>
</para></listitem>
<listitem><para>
  <emphasis role="bold">Three pass encoding</emphasis>?

  x264 offers the ability to make an arbitrary number of consecutive

  (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.
</para></listitem> 
<listitem><para>
  <emphasis role="bold">deblockalpha, deblockbeta</emphasis>:
  This topic is going to be a bit controversial.
</para>
<para>
  H.264 defines a simple deblocking procedure on I-blocks that uses
  pre-set strengths and thresholds depending on the QP of the block

  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 <option>deblockalpha</option> and <option>deblockbeta</option>
  parameters allow you to specify offsets to the preset deblocking
  thresholds.
</para>
<para>
  Many people seem to think it is a good idea to lower the deblocking
  filter strength by large amounts (say, -3).

<row><entry>Description</entry><entry>Encoding options</entry><entry>speed (in fps)</entry><entry>Relative PSNR loss (in dB)</entry></row>
</thead>
<tbody>
<row>
  <entry>Very high quality</entry>
  <entry><option>subq=6:4x4mv:8x8dct:me=3:frameref=5:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>6fps</entry>
  <entry>0dB</entry>
</row>
<row>
  <entry>High quality</entry>
  <entry><option>subq=5:4x4mv:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>13fps</entry>
  <entry>-0.89dB</entry>
</row>
<row>
  <entry>Fast</entry>

20254:beca75a03355

<listitem><para>
  <emphasis role="bold">me</emphasis>:
  This option is for choosing the motion estimation search method.
  Altering this option provides a straightforward quality-vs-speed
  tradeoff. <option>me=dia</option> is only a few percent faster than
  the default search, at a cost of under 0.1dB global PSNR. The 
  default setting (<option>me=hex</option>) is a reasonable tradeoff
  between speed and quality. <option>me=umh</option> gains a little under
  0.1dB global PSNR, with a speed penalty that varies depending on
  <option>frameref</option>.  At high values of
  <option>frameref</option> (e.g. 12 or so), <option>me=umh</option>
  is about 40% slower than the default <option> me=hex</option>. With
  <option>frameref=3</option>, the speed penalty incurred drops to
  25%-30%.
</para>
<para>
  <option>me=esa</option> uses an exhaustive search that is too slow for
  practical use.
</para>
</listitem>

<listitem><para>
  <emphasis role="bold">partitions=p4x4</emphasis>:
  This option enables the use of 8x4, 4x8 and 4x4 subpartitions in
  predicted macroblocks. 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

  prediction is less accurate, but the quality difference is normally much
  too small to be visible. Try, for example, adding
  <option>subq=1:frameref=1</option> to the first pass
  <option>x264encopts</option>. Then, on the second pass, use slower,
  higher-quality options:
  <option>subq=6:frameref=15:partitions=p4x4:me=umh</option>
</para></listitem>
<listitem><para>
  <emphasis role="bold">Three pass encoding</emphasis>?

  x264 offers the ability to make an arbitrary number of consecutive

  (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.
</para></listitem> 
<listitem><para>
  <emphasis role="bold">deblock</emphasis>:
  This topic is going to be a bit controversial.
</para>
<para>
  H.264 defines a simple deblocking procedure on I-blocks that uses
  pre-set strengths and thresholds depending on the QP of the block

  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 <option>deblock</option> allow you to specify offsets to the preset deblocking
  thresholds.
</para>
<para>
  Many people seem to think it is a good idea to lower the deblocking
  filter strength by large amounts (say, -3).

<row><entry>Description</entry><entry>Encoding options</entry><entry>speed (in fps)</entry><entry>Relative PSNR loss (in dB)</entry></row>
</thead>
<tbody>
<row>
  <entry>Very high quality</entry>
  <entry><option>subq=6:partitions=p4x4:8x8dct:me=3:frameref=5:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>6fps</entry>
  <entry>0dB</entry>
</row>
<row>
  <entry>High quality</entry>
  <entry><option>subq=5:partitions=p4x4:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b</option></entry>
  <entry>13fps</entry>
  <entry>-0.89dB</entry>
</row>
<row>
  <entry>Fast</entry>