[MPlayer-DOCS] [PATCH] Compn's suggestions about the section "Choosing the video codec"

[The Wanderer]

Guillaume POIRIER wrote:

> Hello,
> $subj :)
> 
> If there are some obvious mistakes, please tell me so it can be fixed
>  before committing it.

Here's a few points...

(Apparently I'm back in the game, at least slightly. We'll see if it
holds up...)

>  <para>
> -  Choosing the video codec to use depends on several factors, some of
> +  Choosing the video codec to use depends on several factors,
> +  like size, quality, streamability, usability and popularity, some of
>    which widely depend on personal taste and technical constraints.

Well, as before, I still think a phrase like "Which video codec is best
to use" or "Which video codec is best to choose" or "The choice of which
video codec to use"; what these have in common is that they link the
verb "depend" with a noun ("video codec" or "choice") rather than
linking the verb "depend" with the verb "choose".

I would appear to have been voted down last time, though, so...

> -  (To get a better grasp of what the fundamental differences between
> -  MPEG-4 ASP and MPEG-4 AVC are, you would be well advised to read the entry
> -  "<ulink url="http://guru.multimedia.cx/?p=10">15 reasons why MPEG4 sucks</ulink>"
> -  from Michael Niedermayer's blog.)
> +  (advanced codec developers maybe interested in reading Michael
> +  Niedermayer's opinion on
> +  "<ulink url="http://guru.multimedia.cx/?p=10">why MPEG4-ASP sucks</ulink>".)

"may be"

>    Likewise, you should get better quality using MPEG-4 ASP instead
>    of MPEG-2 codecs.

"than you would with MPEG-2 codecs"

(This isn't part of the patch, but it caught my eye.)

>    If you are after blazing speed you should stick around the default
> -  settings of the video codec (which does not mean you should not experiment
> -  with some of the options which are mentioned in other sections
> -  of this guide).
> +  settings of the video codec (you should still try the other options
> +  which are mentioned in other sections of this guide).

I might like to say "(although you should", et cetera, just for reasons
of flow.

>    </para>
>    <para>
>    You may also consider choosing a codec which can do multi-threaded
> -  processing.
> +  processing, which is only useful for users of machines with several
> +  CPUs.

"which" -> "though this" or "even though this"

>    <systemitem class="library">libavcodec</systemitem> MPEG-4 does
> -  allow that, resulting in small speed gains at the price of lower
> -  picture quality.
> -  <systemitem class="library">XviD</systemitem> has some experimental
> -  patches available to boost encoding speed, by about 40-60% in typical
> +  allow that, but speed gains are limited, and picture quality is a
> +  bit affected.

I don't like the phrasing on this last bit. For one thing, it doesn't
say what type of effect is had on the picture quality (it could equally
well be a good effect as a bad one); for another, the positioning of "a
bit" seems wrong to me.

I might say "and there is a slight negative effect on picture quality"
instead. There are certainly other reasonable phrasings.

> +  <systemitem class="library">XviD</systemitem> to boost encoding speed, by about 40-60% in typical
>    cases, with low picture degradation.

This dropped the phrase "has some experimental patches" (see above),
presumably by mistake. If it wasn't a mistake, then note that the result
is not remotely grammatical.

>    <systemitem class="library">x264</systemitem> also allows multi-threaded
> -  encoding, which currently speeds-up encoding by 15-30% while lowering
> -  PSNR by about 0.05dB.
> +  encoding, which currently speeds-up encoding by 15-30% (depending on
> +  the encoding settings) while lowering PSNR by about 0.05dB.

I would prefer to de-hyphenate "speeds up".

>    <emphasis role="bold">Personal taste</emphasis>:
> -  This is where it gets almost irrational: For the same reason that some
> -  hung on to DivX&nbsp;3 for years when newer codecs were already doing wonders,
> -  some folks will prefer <systemitem class="library">XviD</systemitem>
> -  or <systemitem class="library">libavcodec</systemitem> MPEG-4 over
> -  <systemitem class="library">x264</systemitem>.
> +  This is where it gets almost irrational:
> +  Back when the majority of people were using DivX&nbsp;3 and newer
> +  codecs started emerging, some people chose to stick with DivX&nbsp;3.
> +  They might have been afraid of change.
> +  This meant that they lost out on better quality codecs and got stuck
> +  with old DivX&nbsp;3 bugs.
> +  This is also happening today with
> +  <systemitem class="library">libavcodec<systemitem> and
> +  <systemitem class="library">XviD</systemitem> vs the newer codecs
> +  like <systemitem class="library">x264</systemitem>.

I don't like the new phrasing of just about any of this. About the only
advantage I see is that it's slower-paced, which reduces the "skimming"
feel. I could go over it and attempt to rephrase and improve individual
elements, but before I put in the effort I'd like to know why it was
felt that this section needed to be changed at all.

> -  Make your own judgment, and do not always listen to what some people will
> -  tell you to do or think: The best codec is the one you master the best,
> +  Make your own judgement, do not take advice from people who swear by
> +  one codec.

This is two independent sentences, joined with a comma. The simplest fix
is to say "You should make your own judgement; do not" et cetera.

> +  Take a few sample clips from raw sources and compare different
> +  encoding options and codecs to find one that suits you best.
> +  The best codec is the one you master the best,
>    and the one that looks best to your eyes on your display

The repetition of "best" at the ends of the lines here doesn't look good
to me, but I'm not sure either how to justify that or how to fix it.

-- 
       The Wanderer

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

Secrecy is the beginning of tyranny.