[MPlayer-DOCS] CVS: main/DOCS/xml/en encoding-guide.xml,1.8,1.9

[The Wanderer]

Guillaume Poirier CVS wrote:

> +  Experience shows that NTSC contents are a lot more difficult to encode
> +  given that there more elements to identify in the source.

This says that in the case that there are more elements to identify in
the source, NTSC contents are a lot more difficult to encode. Is that
what you meant?

(I'm going to be correcting at least one other thing - the missing
comma, and perhaps "material is" instead of "contents are" - anyway, but
if the above isn't what you meant I can rephrase it a bit at the same
time.)

>    In order to produce a suitable encode, you need to know the original
>    format.
>    Failure to take this into account will result in ugly combing
> -  (interlacing) artifacts in your encode.
> +  (interlacing) artifacts, duplicated or lost frames in your encode.

I'm having a hard time expressing exactly why (even though this time I
know it precisely), but this phrasing of the list is broken. It expands
to "(interlacing) artifacts frames, duplicated frames or lost frames",
and the first of those three is not what you meant. If there were a
third thing to be listed, then "(interlacing) artifacts, duplicated or
lost frames, and/or <foo>" would fix the problem; failing that, then the
best fix I see offhand is something like "Failure to take this into
account will result in various flaws in your encode, including combing
(interlacing) artifacts and duplicated or even lost frames.". That isn't
completely satisfactory, but it's better than nothing.

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

I don't know if I've mentioned it before - I think I must have, since I
know I've seen this line - but I don't like the phrasing "per bitrate".
The simplest fix would be to say "per unit bitrate" instead, but that's
a more formal type of language not necessarily well suited to something
whose tone is not explicitly technical; I'd prefer something else if
such a thing can be found.

> +<para>
> +  Another way to tell if your source is telecined or not is to watch the
> +  the source appending <option>-vf pullup -v</option> to your command line
> +  to see how <option>pullup</option> matches frames.

Two problems here: duplicated "the" (beginning and end of line) and the
fact that it suggests that you watch the source append an option, when
most likely the source will not be able to affect options on its own. A
better phrasing would be something like "watch the source with the -vf
pullup command line option".

> +  If the source is telecined, you should see on the console a 3:2 pattern
> +  with <systemitem>0+.1.+2</systemitem> and <systemitem>0++1</systemitem>
> +  alternating.
> +  This technique has the advantage that you do not need to watch the
> +  source to identify it, which could be useful if you wish to automate
> +  the encoding procedure, or to carry out said procedure remotely via
> +  a slow connection.

Given that you just recommended to watch the source as part of the
suggested procedure, this seems a little inconsistent. I think the
simplest fix would be to say "play" or perhaps "play back" in the
earlier location, instead of "watch".

(Note that I am, of course, open to suggestions and/or objections on any
of this; for most of it, that's why I bothered to post rather than just
committing what I think is better.)

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