[MPlayer-DOCS] CVS: main/DOCS/xml/en mencoder.xml,1.62,1.63

The Wanderer inverseparadox at comcast.net
Sat May 14 06:45:54 CEST 2005


Okay, there were a lot more comments than I expected there to be; some
of them may be issues that I might have skipped over another time, but
you caught me in nit-picky mode today. <grin>

I mostly left out hyphenation comments, since I know my opinion on that
subject does not agree with standard policy; other than that, pretty
much everything I noticed got commented on.


Guillaume Poirier CVS wrote:

> +  The first and most important step before you encode should be
> +  determining what type of content you are dealing with.
> +  If your source material comes from DVD or broadcast/cable/satellite
> +  TV, it will be stored in one of two formats: NTSC for North
> +  America and Japan, and PAL for Europe, etc.

Drop the second "and"; it's not appropriate here unless you want to list
a third format after PAL (and, most likely, say "and so forth" instead
of "etc.".)

> +  But it is important to realize that this is just the formatting for

While the rule is commonly ignored, strictly speaking it is not
appropriate to begin a sentence with "but" (or "and" - both are
connecting words). The simplest rephrase would be to use "It is
important to realize, however," instead.

> +  Besides being ugly, the artifacts also harm coding efficiency:
> +  You will get worse quality per bitrate.

The word following a colon does not automatically get capitalized.

> +  <emphasis role="bold">PAL video</emphasis>: Recorded with a PAL
> +  video camera at 50 fields per second.
> +  A field consists of just the even or odd numbered lines of a
> +  frame.

I would hyphenate these - "even- or odd-numbered" - partly because it
helps associate "even" with "numbered" better and partly because that's
how I'd write either word alone. Standard hyphen policy may disagree,
though.

Also, it's more common to put "odd" first, though there's no particular
reason that has to be adhered to.

> +  Television was designed to refresh these in alternation as a
> +  cheap form of analog compression.
> +  The human eye supposedly compensates for this, but once you
> +  understand interlacing you will learn to see it on TV too and
> +  never enjoy TV again.

I'd say "as much" before "again" here.

> +<listitem><para>
> +  <emphasis role="bold">Animation</emphasis>: Usually drawn at
> +  24fps, but animation also comes in mixed-framerate varieties.

Remove the word "animation" here, for parallel with the first half of
the sentence; the second verb already has an object, the same as the
first one does.

> +</para></listitem>
> +<listitem><para>
> +  <emphasis role="bold">Computer Graphics (CG)</emphasis>: Can be
> +  any framerate, but 24 and 30 fps are the most frequently
> +  encountered in NTSC regions, and 25 fps in PAL regions.

There's a problem with the fact that as this is phrased, the modifier
"most frequently" applies only to the NTSC part, not to the PAL part.
The simplest fix would be to move the verb phrase ("the most frequently
encountered") to before the frame rates.

Another, more radical but possibly superior, fix would involve something
along the lines of: "Can be any framerate, but some are more common than
others; 23 and 30 are typical for NTSC, and 25 is typical for PAL.".
Eliminates slightly awkward commage, and avoids the core problem at
least equally well.

Also: elsewhere you have usages like "24fps", but here you have "25
fps". Presumably this is because it would be awkward to say "24 and
30fps", and at least nearly equally so to say "24fps and 30fps"; still,
it might be worth trying to keep things consistent.

> +<title>Identifying source material</title>
> +<para>
> +  Movies consisting of frames are referred to as progressive,
> +  while those consisting of independent fields are called
> +  interlaced, or sometimes video, although this latter term is
> +  ambiguous.

The combination of phrasing and commas doesn't quite work out right
here. I see two possible fixes right away: either

"are referred to as interlaced, or sometimes as video,"

(which more closely links the noun "video" with its verb, reducing the
grouping problem) or

"called either interlaced or video - though this"

(which removes the comma, and associated grouping, problem entirely) or

"interlaced. The latter type are sometimes also called video, although
the term is ambiguous.".

which now that I look at it seems less than ideal in its own way.
Personally I'd probably prefer the second of these, but you can choose
whatever you like.

> +  Unless the original material was also field-based (and the same
> +  fieldrate), you are getting the movie in a format other than the
> +  original.

I'd separate "fieldrate" here - it doesn't look right as one word in
this context, especially not right after the hyphenated "field-based".

> +<title>There are several common types of pulldown:</title>
> +<listitem><para>
> +  <emphasis role="bold">PAL 2:2 pulldown</emphasis>: The nicest of
> +  them all.

Is this form of pulldown exclusive to PAL? If not, it might be a good
idea to include only its technical name ("2:2 pulldown") in the
<emphasis> tags, and add a note afterwards to the effect that it appears
primarily in PAL.

Similar comments apply to each of the other pulldown types.

> +  Each frame is shown for two fields duration, by extracting the
> +  even and odd lines and showing them in alternation.

Does this mean "the duration of two fields"? If so, I'd phrase it that
way, for clarity (or, at bare minimum, use "fields'" instead - the
apostrophe on the end is required to indicate the possessive form of the
plural "fields"). If not, I don't understand what it does mean, so it
needs to be rephrased in some other way.

Similar comments apply to the comparable lines in the other types'
descriptions.

> +  <emphasis role="bold">NTSC 3:2 telecine</emphasis>: Frames are
> +  shown alternatively for 3 fields or 2 fields duration.

ITYM "alternately".

> +  This gives a fieldrate 5/2 times the original framerate.

See above re "fieldrate" (although it might be more awkward, here and
elsewhere, to have "field rate" and "framerate" - and I don't think I'd
like to propose separating the latter); also, while "5/2" makes it
slightly easier to see where the number came from, in purely grammatical
terms I'd prefer to say "2.5" instead. (Try reading the sentence out
loud both ways - you should see the problem I'm talking about.)

> +  There are also methods for converting between NTSC and PAL video.
> +  Such topics are beyond the scope of this guide.

I'd combine these two sentences with a comma and a "but". It's valid as
it is, however, I just think the other way flows better.

> +  NTSC/PAL conversion is highly destructive and cannot be reversed
> +  cleanly, so your encode will greatly suffer if it is made from a
> +  converted source.

While I don't like the "NTSC/PAL" usage (specifically the "/"), I admit
that any other way of referring to conversion in both directions which
springs readily to mind is lengthier and probably more awkward (or at
least repetitive, as with "Conversion between NTSC and PAL"); if you can
come up with some better way of expressing it I'd be happy, but it's
probably best left as it is.

(Or... hmm. Would "Conversion between these two formats is highly
destructive" work?)

> +  The MPEG-2 standard used on DVD and digital TV provides a way to
> +  encode the original progressive frames, and store the number of
> +  fields for which each should be shown in the frame headers.

Depending on exactly what is meant, I'd drop the comma and either say "a
way to both" or "a way to encode ... and a way to store".

I also don't understand offhand what is meant by "for which each" here.
At a minimum: each what? Each frame? Each field?

Actually, looking at it again "frame" seems more likely. In that case
something like "store in the header of each frame the number of fields
for which it should be shown" would I think be clearer.

> +  If this method has been used, the term "soft telecine" will often
> +  be used to describe the movie, since the process only directs the
> +  DVD player to apply pulldown to the movie rather than altering
> +  the movie itself.

Technically "soft telecine" doesn't describe the movie, it describes a
characteristic of the movie's format. A less-than-ideal way of being
more accurate without going into that at length would be to say "the
movie will often be described as "soft-telecined", since". Alternately,
you could say "This method is often referred to as "soft telecine",
since".

> +  However, many DVD and broadcast production studios do not use
> +  proper encoding techniques, and instead produce movies with
> +  "hard telecine", where fields are actually duplicated in the
> +  encoded MPEG-2.

Drop the comma after "techniques". The result isn't ideal but is within
tolerances. If you want, you could also change the following "and" to
"but".

> +  If <application>MPlayer</application> never shows the framerate
> +  change, and every single frame with motion appears combed, your
> +  movie is NTSC video at 59.94 fields per second.

I don't like the usage "shows the framerate change" here (or immediately
below). The simplest fix would be to simply say "changing" instead.

> +  If <application>MPlayer</application> never shows the framerate
> +  change, and two frames out of every five appear combed, your
> +  movie is "hard telecined"
> +  24fps content.

Does the same only-frames-with-motion restriction mentioned above with
respect to combing also apply here (and below)? If so, you might want to
mention it, although the single mention might be enough to convey the
idea for the entire section.

I also don't see any reason for the final linebreak; it does no harm,
but it doesn't seem to benefit anything.

>  <sect2 id="menc-feat-dvd-mpeg4-2pass">
>  <title>Constant Quantizer vs. two pass</title>

Any particular reason why these first two words are capitalized?

> +  It is possible to encode your movie at a wide range of qualities.
> +  With modern video encoders and a bit of pre-codec compression
> +  (downscaling and denoising), it is possible to achieve very good
> +  quality at 700 MB, for a 90-110 minute widescreen movie.
> +  And all but the longest movies can be encoded with near-perfect
> +  quality at 1400 MB.

This sentence begins with "and", which is inappropriate. If you want to
retain the same meaning with minimal change, something like "What's
more" or "Furthermore" could be used to replace it.

> +</para>
> +
> +<para>
>    There are three approaches to encoding the video: constant bitrate
>    (CBR), constant quantizer, and two pass (ABR, or average bitrate).

Isn't that last more appropriately "multi-pass"? If so, it might be good
to change the section title too. (A comment to the effect that two
passes is typical ought to be enough to cover the fact that the ensuing
section only addresses two-pass encoding.)

> +  While deinterlacing will make your movie usable on progressive
> +  scan displays such a computer monitors and projectors, it comes
> +  at a cost: The field rate of 50 or 59.94 fields per second
> +  is halved to 25 or 29.97 frames per second, and roughly half
> +  the information in your movie will be lost during scenes with
> +  significant motion.

Missing word: "half of"

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




More information about the MPlayer-DOCS mailing list