[MPlayer-DOCS] CVS: main/DOCS/xml/en encoding-guide.xml,1.5,1.6

[The Wanderer]

Guillaume POIRIER wrote:

> Hi Wanderer
> 
> On 8/12/05, The Wanderer <inverseparadox at comcast.net> wrote:
> 
>> Guillaume Poirier CVS wrote:
>> 
>>> +<para>
>>> +  The complexity (and thus the number of bits) required to compress the
>>> +  frames of a movie can vary greatly from one scene to another.
>> 
>> Suggest "The complexity of the frames of a movie, and thus the
>> number of bits required to compress them, can" et cetera.
> 
> Okay with me.

Right. This is one of the changes I'd have just committed without
pointing out, except that there was something else which I did want to
get input on, and I figured I might as well give people a chance to
object if they did want to.

>>> +  Modern video encoders can adjust to these needs as they go and vary
>>> +  the bitrate.
>>> +  However, in simple modes such CBR, they cannot exceed the requested
>>> +  average bitrate for long stretches of time, because they do not know
>>> +  the bitrate needs of future scenes.
>> 
>> Missing word: "such as".
>> 
>> I'm not positive it's incorrect, but I don't like the way the third
>> comma makes the sentence flow; it *feels* wrong to me, even if it
>> may be perfectly acceptable in formal terms. The only fix which
>> comes to mind would be to simply drop that comma, and I'm reluctant
>> to do that because I think I'd have objected to *that* form if it
>> had been the one which came through.
> 
> That's what Rich wrote. I'm not very good at English typography 
> myself. Original version doesn't hurt my eyes so badly that I need to
> close them not to faint, but I trust you on this. Go ahead and
> change it your way! :)

Ah, but that's the trouble, you see: I don't *have* a "my way" here.
Both the form with the third comma *and* the form without it strike me
as wrong, in slightly different ways. The only fix I see which does not
have that kind of problem is considerably more invasive, something along
the lines of "However, in simple modes such as CBR the encoders do not
know the bitrate needs of future scenes, and so cannot" et cetera... but
that *also* has problems, albeit lesser ones, to do with what order it
makes sense to present the ideas in.

Actually that more-invasive form is probably better than either the
current form or my previous suggestion, although it's still far from
satisfactory. If no one has any suggestions for further improvement,
I'll commit the various changes with that form sometime this evening or
tomorrow.

>>> +  Wiser modes, such as multipass encode can take into account the
>>> +  statistics from previous passes, which fixes the problem mentioned
>>> +  above.
>> 
>> Add a comma after "encode", and replace "passes, which" with
>> "passes; this".
>> 
>> I also don't like the usage "Wiser modes" here, but I'm not sure
>> what to do to fix the problem; the most obvious parallel to "simple
>> modes", above, would be "More complex modes", but I'm not sure how
>> well that works.
> 
> Right. Okay with me. I was also thinking of "more advanced modes" as
> two pass is not really more complex but makes more intelligent 
> decisions. See what I mean?

That also works, and in some ways is preferable; I chose "more complex"
because complexity is the reverse of simplicity, and it makes sense to
parallel the earlier usage of "simple" (as I noted). I'll go with "more 
advanced" unless someone recommends otherwise.

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