[MPlayer-DOCS] XviD encoding guide

[The Wanderer]

Guillaume POIRIER wrote:

> Hello everyone,
> Please find in this mail the first part of XviD's encoding guide. It
> lacks the description of more advanced options of MPEG-4 ASP, the
> PSNR and speed delta to expect from each option (which would require
> me to run some benchmarks, but I'm time-shorted right now, so I'll do
> that later), and some encoding examples.
> 
> I think that this is a decent starting point, so here it is, for
> review and inclusion in our main doc.

Well, I wasn't going to get to this for a few days (since it seemed
large at a glance - I no longer know why, but it did), because of quirks
of my work schedule - but I was sitting here looking for things to do to
postpone going to bed, and you mentioned my name so here I am. ^_^

(After writing: That was just as much of a job as I'd expected it to be.
Still, that just meant it needed to be done that much more, eh?)

>  The XviD's default settings are already a good trade-off between
>  speed and quality, therefore you can safely stick to them if
>  the following section puzzles you.

The phrase "The XviD's default settings" is redundant - either drop the
"The", or say "The default XviD settings" or "The XviD default settings"
or "The XviD defaults" or "The default settings of XviD" or the like
(I'm in an odd mood tonight, can you tell?). The former fix is of course
simplest.

>  <emphasis role="bold">vhq</emphasis>
>    Default setting may be safely used for every encode, while higher
>    settings always help PSNR, but are significantly slower.

Hmp. Looks like I may have been wrong all this time about what "vhq"
actually means - I took it to be an acronym for "very high quality",
intended to signify that "this option improves quality per unit
filesize", but if the description in the XviD section of the man page
(which I actually hadn't read before) is accurate then it appears to
stand for something like "vertical/horizontal quantizer", which would be
much different.

On the grammatical side: you're missing the definite article at the
beginning of the sentence ("The default"). Also, I don't like splitting
the sentence the way the second comma does; it's not actually invalid as
is, but I think it works better with that comma removed.

>    Please note that a better PSNR do not necessarily mean
>    that the picture will looks better, but tells you that it is
>    closer to the original.

beastd already commented on part of this ("looks" -> "look", but missed
a more severe problem: there is a tense inconsistency between "do" and
"tells", not to mention a case inconsistency (I think that's the term?)
between the singular "a" and the plural/collective "do". The simplest
and possibly best fix is to say "does" instead.

>    Turning it off will noticeably speed-up encoding if you need speed.

Actually it will noticeably speed up encoding anyway, it's just that it
may not be worth the tradeoff if speed isn't critical. I might in fact
suggest almost exactly that: "Turning it off will noticeably speed up
encoding; if speed is critical for you, the tradeoff may be worth it."
If you prefer, the "if speed is critical for you" can remain the current
"if you need speed" - it's just a suggestion.

In adherence to general documentation policy (and, this time, my own
instincts), "speed up" should not be hyphenated.

>  <emphasis role="bold">bvhq</emphasis>
>    This does the same job as vhq, but does it on B-frames.

Hyphenation policy - unless I have it backwards all of a sudden? A quick
glance at the man page seems to say maybe I do. I'll assume that that's
the case; if it isn't, take note that this usage occurs throughout.

It might be worthwhile to specify (either here or in the vhq section)
what it is which vhq operates on, since we specify that bvhq operates on
B frames. That probably depends on how technical we want this guide to
get.

>  <emphasis role="bold">max_bframes</emphasis>
>    A higher number of consecutive allowed B-frames usually improves
>    compressibility while this may lead to more blocking artifacts.

Unless you actually mean that improving compressibility may lead to more
blocking artifacts, this is not accurate as it stands; even if you do
mean that, it isn't technically correct. If you mean that increasing the
number of consecutive allowed B frames may lead to more blocking
artifacts, then you want to say "compressibility, but may lead to" or
"compressibility, although it may also lead to" instead.

>    Default setting is a good trade-off between compressibility and
>    quality, but you may increase it up to 3 if you're bitrate-starved.

Missing definite article - "The default"; same as under vhq.

>    You may also decrease it to 1 or 0 if you're aiming at perfect
>    quality though in this case, you should make sure your
>    target bitrate is high enough to ensure that the encoder doesn't
>    have to increase quantizers to reach it.

Move the comma backwards four words, to after "quality"; that's where
the break in the structure of the sentence is. I might also say "that
case" instead of "this case".

>  <emphasis role="bold">bf_threshold</emphasis>
>    This controls the B-frame sensibility of the encoder, where a higher
>    value leads to more b-frames being used (and vice versa).

Sensibility, or sensitivity? In certain comparatively obscure senses
"sensible" can mean "aware" (such that "sensible of" means "taking into
account"), so the meaning could be close enough, but although the usage
is formally valid I think most people are unlikely to be aware of that
meaning; I pride myself on my vocabulary, or I used to, and it took me a
moment to remember it.

Capitalization on the second occurrence of "B-frames".

>    This setting is to be used together with <option>max_bframes</option>,
>    so if you are bitrate-starved, you should increase both
>    <option>max_bframes</option> and <option>bf_threshold</option>,
>    while you may increase <option>max_bframes</option> and reduce
>    <option>bf_threshold</option> so that the encoder may use more
>    B-frames in places that only <emphasis role="bold">really</emphasis>
>    need them.

Too much commage IMO; the simplest fix which presents itself would be to
replace the first comma with a sentence break, either a period or a
semicolon, and drop the following "so". Alternately (or additionally)
you could drop the second comma, but that introduces flow problems of
its own.

>    However, if you need to be compatible with standalone players that
>    only supports old DivX profiles (which only supports up to 1
>    consecutive B-frame), this would be you only possibility to
>    increase compressibility through using B-frames.

Aside from the "you" -> "your" issue: while "possibility" has meaning
here, I don't like it in this context. (I can think of at least one
other way to phrase the entire idea which would make it the appropriate
word, but I don't want to go that far on so little cause.) The simplest
fix would be to say "way" instead.

>  <emphasis role="bold">trellis</emphasis>
>    Optimizes the motion estimation and allows significant bit saving
>    which would be spent elsewhere on the video, raising overall visual
>    quality.

As this stands it says that bit saving would be spent on video - and it
sounds odd to me to say that "saving" would (apparently implying, would
otherwise) be "spent". I don't see any fixes which don't involve
rephrasing the entire sentence and/or considerably simplifying its
technical aspect; I thought I had one such rephrasing fix a moment ago,
but it doesn't come to mind, so if you can suggest one - or something
less intrusive - please feel free.

>    You should always leave it on as its impact on quality is very
>    sensible, but if you're looking for speed, only disable it if you
>    have turned down <option>vhq</option> and all other more CPU-hungry
>    options to the minimum.

Break the sentence (preferably with a period) after "sensible".

I'd say "Even if you're looking for speed, don't disable it until you
have" et cetera.

>  <emphasis role="bold">me_quality</emphasis>

>    Default setting is best in pretty much all cases, and it's not
>    recommended to turn it down unless you're really looking for speed,
>    as all the bits saved by a good motion estimation would be spend
>    elsewhere, raising overall quality.

Again "Default" -> "The default".

"spend" -> "spent"

This feels like it has too many commas as it stands; I'd recommend
splitting it with a semicolon after "cases".

>    Therefore, only go as low as 5, and only as a last resort.

I'd probably say "don't go any lower than" instead, and add "that" or
"even that" before "only".

>  <emphasis role="bold">chroma_me</emphasis>
>    Improves motion estimation by taking the chroma (the color)
>    information into account, when <option>me_quality</option> alone
>    only uses luma (greyscale).

Repetition of "the" w.r.t. "chroma" and "color"; I'd probably drop the
one in the parentheses.

Does this option have the described effect only at times when me_quality
is only using luma? If not, then the word you probably want is
"whereas".

>    This slows down encoding by 5-10% but improves quite a bit visual
>    quality by reducing blocking effect.

Move the phrase "visual quality" backwards three words, to before "quite
a bit".


Other than that, looks good, except for one general comment: most of the
option sections start with a one-sentence (or fragment-sentence)
description of what the option does, but the "vhq" option begins with a
comment about the option's default. For general consistency it should
probably be changed to parallel the others.

-- 
       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.