[MPlayer-DOCS] more x264 encoding guide updates

[Diego Biurrun]

On Sun, Jul 03, 2005 at 12:31:20AM -0500, Jeff Clagg wrote:
> First I would like to apologize to anyone who is irritated by my mix of
> content, organizational, cosmetic and/or completely pointless changes
> (depending on your perspective). If you would like a quick-and-easy text
> view of the final results, see
> http://ikaruga.co.uk/~snacky/menc-feat-x264.txt
> 
> +  but that isn't what they're primarily useful for. A couple of the

Please avoid short forms, it's the style of the docs not to use them.

> -  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 is a dubious proposition because 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
> -  differences in the achieved bitrate.
> +  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.

Please avoid mixing cosmetics and other changes, it makes your patches
harder to review.  I don't generally forbid cosmetic changes but they
should come in separate patches.

> @@ -2261,7 +2280,6 @@
>    This issue is probably extremely rare in live action video material,
>    but it does sometimes come up in video game captures.
>  </para></listitem>
> -
>  <listitem><para>
>    <emphasis role="bold">me</emphasis>:
>    This option is for choosing the motion estimation search method.

same here

> -  The usefulness of B-frames is questionable in most other codecs
> -  you may be used to.
> -  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.
> +  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.

Here for example you did some rephrasing, above you didn't.  That's
easily overlooked if cosmetics are mixed with other changes.

> +  <emphasis role="bold">2-pass</emphasis>:
> +  Above, it was suggested to always use 2-pass, 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; in the case that you use the exact same
> +  set of options on both passes, 2-pass is almost twice as slow.

  think we settled for the spelling "two pass".

> +<para>
> +  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

General remark: If you keep lines shorter (60-70 characters) it becomes
easier to make patches that make small changes without going over the 80
characters limit of most terminals.  This is not a general policy, just
a hint.

Looks excellent otherwise, I'm sure Guillaume will apply it in no time.

Now if you guys could have a go at the lavc documentation ;)

Diego