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

[Guillaume POIRIER]

Hi,

On 5/14/05, The Wanderer <inverseparadox at comcast.net> wrote:
> Guillaume Poirier CVS wrote:
> 
> > Log Message:
> > Nits and corrections suggested by The Wanderer
> 
> A few mistakes I see:
> 
> > -  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.
> 
> > +  The MPEG-2 standard used on DVD and digital TV provides both a
> > +  way to encode the original progressive frames, and to store in
> > +  the header of each frame the number of fields for which it should
> > +  be shown.
> 
> What I actually suggested here - or at least what I meant to suggest, I
> may have been asleep - was one of "a way to both encode .. and store" or
> "a way both to encode ... and to store" or "both a way to encode ... and
> a way to store"; the current form exhibits just as much of the problem
> that was meant to solve as did the previous form.

Well, your suggestions were absolutely correct, but I thought I was
smart enough to adapt it a bit... Bad idea.
Fixed.


> In any case, regardless of which of the three forms you prefer, the
> comma is not IMO appropriate.
> 
> >    If <application>MPlayer</application> never shows the framerate
> > -  change, and every single frame with motion appears combed, your
> > +  changing, and every single frame with motion appears combed, your
> >    movie is NTSC video at 59.94 fields per second.
> >  </para></listitem>
> >  <listitem><para>
> >    If <application>MPlayer</application> never shows the framerate
> >    change, and two frames out of every five appear combed, your
> 
> Oops - missed change, probably because I only mentioned it in a "Similar
> comments apply" bit; the above "change" -> "changing" applies in this
> latter place as well.

Fixed.


> > +<note><title>Note:</title>
> > +<para>
> > +  Most codecs which support ABR encode only support two pass encode
> > +  while some others such as <systemitem class="library">x264</systemitem>
> > +  and <systemitem class="library">libavcodec</systemitem> support
> > +  multi-pass, which slightly improves quality at each pass,
> > +  yet this improvement is no longer noticeable after the 6th or so pass.
> > +  Therefore, in this section, two pass and multi-pass will be used
> > +  interchangeably.
> 
> Hyphenation policy again... I said "multi-pass" because that's what
> makes sense to me and how I'd write it, but using it in the actual
> documentation is inconsistent with also using "two pass". If you aren't
> going to change to "two-pass" everywhere except where that would be
> specifically inappropriate, I'd recommend using "multipass", since that
> form can be compounded whereas "twopass" cannot.

Fixed too. I have more fixes for this exact paragraph anyway, so I'm
gonna commit the changes right now.

Guillaume