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

[Diego Biurrun]

On Sat, May 14, 2005 at 12:45:54AM -0400, The Wanderer wrote:
> 
> Guillaume Poirier CVS wrote:
> 
> >+  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.

I've found no clear rule on this and settled on the following: If there
is a full sentence (verb and all) after the colon it gets capitalized.
I'm not sure what the official rule is in English.  I thought this was
the rule in German, but I'm not 100% certain anymore.

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

I agree.

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

While I would normally agree here, this completely distorts what Rich is
saying, he'd never make such a balanced and non-controversial statement,
so I'll reject this change ;-)

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

I've wondered myself what the best way to solve this would be.

> 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);

Since the spelling of framerate is fixed already, I'd be tempted to go
with fieldrate to match it, even though I admit it looks a tad awkward.

> >+  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?)

I think both "Conversion between NTSC and PAL" and "Conversion between
these two formats is highly destructive" are better, Guillaume gets to
choose.

I agree with all the rest.  Guillaume, apply ;-)

Diego