[MPlayer-dev-eng] [RFC] preliminary x264 encoding help text

[The Wanderer]

Jeff Clagg wrote:

> Hi, I'm doing some preliminary work on a document that will provide
> encoding tips for users of x264.

> When this document is in decent shape, I will adapt it for inclusion
> in DOCS/xml/en/mencoder.xml (which, btw, rocks, and should probably
> be referenced multiple times in the man page). Meanwhile I'd be very
> grateful for any comments or contributions.

I don't know anything about H.264 or x264 beyond what also applies to
encoding in general, but I do have a few proofreading comments.
(Surprisingly few, all in all; your overall writing quality is quite
good, especially for something which reads almost conversationally.)

> There are mainly three types of considerations when choosing encoding
> options:
> 
> 1) Trading off encoding time vs. quality
> 2) frame type decision options
> 3) ratecontrol and quantization decision options

These three should be consistently capitalized: either all three of them
should be capitalized ("Trading", "Frame", "Rate control") or none of
them should.

(Whether to use "rate control" or "ratecontrol" is another question,
which IIRC has an official MPlayer-documentation answer but whose answer
I forget; Diego would probably know.)

> Before continuing, I should explain that I'm using only one quality
> metric: global PSNR. This is reported as the last PSNR number reported
> when you include the "psnr" option in x264encopts. Any time I make a
> claim about PSNR, one of the assumptions behind the claim is that equal
> bitrates are used.

I'm not sure it's worth explaining it here, but I'll note (as I've done
recently) that not everyone trying to do encoding knows what PSNR stands
for; especially if this guide is in any way aimed at encoding newbies,
it might be good to expand the term in parentheses at the first usage.

> Nearly all of my comments assume you're using 2-pass. When comparing
> options, there are two major reasons for using 2-pass encoding. First,
> using 2-pass usually gains around 1.5db PSNR, which is a very big
> difference.

Here and throughout: the correct abbreviation for "decibel" is "dB", not
"db". I'm not entirely sure why, but TTBOMK it's true.

> bframes:
> 
> The usefulness of b-frames is questionable in most other codecs you
> may be used to.

"B-frames" (here and throughout) - again, this was settled on as the
standard for the MPlayer documentation. I personally don't like the
hyphen, but I'm not in charge.

> In h.264, this has changed:

"H.264" - also in at least one place below.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.