[MPlayer-DOCS] [PATCH] Choosing the video codec

[The Wanderer]

On 12/26/2005 06:02 PM, Guillaume POIRIER wrote:

> Hi,
> On 12/26/05, Guillaume POIRIER <gpoirier at mplayerhq.hu> wrote:
> 
>> Hi,
>> 
>> Alexander Strasser a écrit :
> 
>> You're right. Please find in attachment the updated version that 
>> features all of the suggestions so far.
> 
> Yet another updated version (which will probably be the one that will
>  make its way to CVS soon) before I meed Mr Sandman. ;-P

Or perhaps not. I've beeon holding off on commenting both because I was
doing other things and because there were enough comments already made
that an excessively large number of mine would probably have been
redundant... let's see what I think of it now.

> +<sect2 id="menc-feat-dvd-mpeg4-codec">
> +<title>Choosing the video codec</title>
> +
> +<para>
> +  Choosing the video codec to use depends on several factors, some of
> +  which widely depend on personal taste and technical constraints.

As this is phrased, you are saying a verb ("to choose") depends on
something. To the best of my ability to assess matters at the moment, I
believe that only a noun can be used with "depend" like that.
Technically speaking what you mean is something like "Which video
codec(s) would be good choices to use depends on" et cetera - I would
not recommend that exact phrasing, because it's awkward enough on its
own, but it avoids the base problem. Do you see what I mean?

In this case I do not think that the double use of "depend" in such
quick succession is a problem.

> +  <listitem><para>
> +  <emphasis role="bold">Compression efficiency</emphasis>:
> +  It's quite easy to understand that newer generation of codecs are made
> +  to yield better picture quality than previous generations.

Inconsistent plurality - either "newer-generation codecs" or "newer
generations of codecs".

> +  Therefore, you cannot be wrong
> +  <footnote id='fn-menc-feat-dvd-mpeg4-codec-cpu'>
> +  <para>Be careful though: decoding DVD-resolution MPEG-4 AVC videos
> +  requires a fast machine (i.e. a Pentium 4 over 1.5Ghz or a Pentium M
> +  over 1Ghz).
> +  </para></footnote>
> +  choosing MPEG-4 AVC codecs like

"be wrong choosing" -> "go wrong by choosing" (or similar)

I would probably recommend inserting a comma after "careful". It also
might not be a bad idea to use "however" instead of "though".

> +  (To get a better grasp of what are the fundamental differences between
> +  MPEG-4 ASP and MPEG-4 AVC are, you should definitely read the entry

Repetition of "are" - the better fix is to drop the first one.

> +  "<ulink url="http://guru.multimedia.cx/?p=10">15 reasons why MPEG4 sucks</ulink>"
> +  from Michael Niedermayer's blog.)
> +  Likewise, you should get better quality using MPEG-4 ASP instead
> +  of MPEG-2 codecs.

"should" used in consecutive sentences with different meanings. It would
be cleaner to say something like "you can read the entry" or, to
preserve something closer to the current meaning at the expense of
highfalutin' verbosity, "you would be well advised to read the entry" in
the first occurrence.

> +  <para>
> +  However, newer codecs which are in heavy development can suffer from
> +  some bugs which have not been spotted at the time you used that codec,
> +  ruining your encode.

Tense inconsistency ("have not been", "used") and a general ill-at-ease
feeling. Perhaps something like "can suffer from bugs which have not yet
been noticed and which can ruin an encode"?

> +  That's unfortunately sometimes the price to pay for bleeding edge
> +  technologies.

I don't like this phrasing at all. I could probably fix it in something
resembling its current form, but it would be simpler to say something
like "This is simply the tradeoff for using bleeding-edge technology.".

> +  <para>
> +  What's more, newer codecs mean in general that you'd need some training
> +  time to get used to their set of options so that you know what to tune
> +  depending on what kind of picture quality you're after.

This isn't a characteristic of "newer codecs", but of "codecs you're not
familiar with".

"What's more, beginning to use a new codec requires that you spend some
time becoming familiar with its available options, so that you know what
to adjust to achieve a desired picture quality."

(Or you can rephrase that further if you like, I don't claim it's
perfect.)

> +  <listitem><para>
> +  <emphasis role="bold">Hardware compatibility</emphasis>:
> +  Standalone video players usually take a long time to include capability
> +  for the latest video codecs.

"It usually takes a long time for standalone video players to begin to
include support for the latest video codecs."

As things are currently phrased, it seems to imply that if you wait long
enough, your current standalone video player will eventually develop the
ability to play the latest codecs. Except in the case of players which
can be updated by flashing the memory or the like, which for all I know
may not exist, this is plainly a ludicrous notion.

> +  That means that most only support MPEG-2 and MPEG-4 ASP
> +  (beware: usually, not all MPEG-4 ASP features are supported).

"As a result, most only support"

> +  Please refer to the technical specs of your player for more informations.

"information" - plurality

> +  <listitem><para>
> +  <emphasis role="bold">Best quality per fps</emphasis>:

Per FPS?? What does the frame rate have to do with quality, unless it's
'way too low (say, below 20 frames per second)?

Unless you're referring to "the time it takes to encode" or "the time it
takes to decode", in which case all I can say is that this is a very
strange way of talking about matters.

> +  Codecs that have been around for some time (such as
> +  <systemitem class="library">libavcodec</systemitem> MPEG-4 and
> +  <systemitem class="library">XviD</systemitem>) are usually heavily
> +  optimized using all kinds of smart algorithms and SIMD assembly code.

I would probably prefer to say "with" rather than "using".

> +  That's why they tend to yield the best quality per fps.
> +  However, they may have some very advanced options that, if enabled,
> +  will make the encode really slow for marginal gains.

I would personally prefer to say "which" rather than "that" here, but it
is my understanding that the formal rule disagrees with me.

> +  <para>
> +  If you are after blazing speed you should stick around the default
> +  settings of the video codec (which doesn't mean you should not experiment
> +  with some of the options which are mentioned in other sections
> +  of this guide).

"stick around" - does that mean "stay in the close vicinity of", as in,
"do not adjust very far from"? Or do you simply mean "stick with"?

> +  <para>
> +  You may also consider choosing a codec that can do multi-threaded
> +  processing.

As above for "that" vs. "which".

> +  <systemitem class="library">libavcodec</systemitem> MPEG-4 does
> +  allow that, at the price of lowering picture quality for small speed
> +  gains.

I would probably say "resulting in small speed gains at the price of
lower picture quality", or similar.

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

I would prefer to set out the "by about 40-60% in typical cases" somehow
- not very satisfactory, but better than anything else I've come up with
so far, is simply with commas.

> +  <listitem><para>
> +  <emphasis role="bold">Personal taste</emphasis>:
> +  This is were it gets almost irrational: For the same reason that some
> +  hanged on to DivX3 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>.

"where it gets"

"hung on to"

Is that "DivX3", or "DivX 3"?

I'll note that x264 can, in fact, be undesirable if the video will have
to be played back on a slower system - not every computer out there is
remotely powerful enough to play back even reasonably low-resolution
H.264 at full speed.

> +  <para>
> +  Make your own judgment, and don't always listen to what some people will
> +  tell you to do or think: The best codec is the one you master the best,
> +  and the one that looks best to your eyes on your display
> +  <footnote id='fn-menc-feat-dvd-mpeg4-codec-playback'>
> +  <para>The same encode may not look the same on someone else's monitor or
> +  when played back by a different decoder so future-proof your encodes by
> +  playing them back on different setups.</para></footnote>!

Comma after "decoder".

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