[MPlayer-DOCS] CVS: main/DOCS/man/en mplayer.1,1.747,1.748

The Wanderer inverseparadox at comcast.net
Mon Sep 27 07:53:03 CEST 2004


Given the number of comments below, apparently I didn't examine the 
patch quite as closely as I should have. ^_^


Guillaume Poirier CVS wrote:

> +Imagine a scene with a bird flying across the whole scene, tcplx_mask
> +will decrease the quantizers of the bird's macroblocks (thus decreasing their
> +quality) as the human eye usually does not have time to see all the bird's
> +details.

You need a break - either a sentence break or a semicolon - after
"scene", and a comma after the close-paren.

> +Be warned that if the masked object stops (e.g.\& the bird lands) it is
> +likely to look horrible for a a short period of time (until the encoder
> +figures out that the object is not moving and needs refined blocks).
> +The saved bits will be spent on other parts of the video, which may increase
> +subjective quality, provided that tcplx_mask is carefully chosen.

The effect of the second set of parentheses can be accomplished better
by, instead, putting a comma after "time".

> +Imagine a scene with grass (which usually has a great spatial complexity),
> +a blue sky and a house, scplx_mask will raise the quantizers of the grass'
> +macroblocks (thus decreasing its quality), in order to spend more bits on
> +the sky and the house.

Drop the "a" before "great", insert a break (again, either sentence
break or semicolon) after "house", and either drop the comma after
"quality" or remove the second set of parentheses and add a comma after
"macroblocks".

> +This setting does not have the same effect as using a custom matrix that
> +whould compress high frequencies harder, as scplx_mask will reduce the
> +quality of P-blocks even if only DC is changing, which will probably not
> +look as good.

Something about the commas here doesn't hit me right, but I'm not sure
how to fix it. It seems as if the sentence is complete at "changing"
(and there would be no problems if the comment ended there), but instead
it continues; I'm not sure, but I think the problem might be partly
related to the fact that it is unclear what the antecedent to the word
"which" is.

One possible fix: add a break after "harder", and replace the following
"as" with "This is because". (Or, possibly, put the break after
"changing", and replace "which" with "The result". It's possible to
combine the best aspects of these two, but I don't want to either
provide too many (and, thus, too confusing) suggestions or make only one
suggestion which performs unnecessarily radical surgery on the
sentence.)

(Speaking of consistency, as we were a little bit ago elsewhere, if
we're not going to say "I-frames" we also probably shouldn't say
"P-blocks".)

> +Reduces the quality of inter blocks, which is equivalent to increasing
> +the quality of intra blocks, since the same average bitrate will be
> +distributed by the rate controller to the whole video sequence

As it stands, this could equally well be saying "This reduces the
quality of inter blocks because the same average bitrate will (etc.)",
or "Because the same average bitrate will (etc.), reducing the quality
of inter blcoks is equivalent to increasing the quality of intra
blocks." On the assumption that it really means the latter, I'd suggest
adding a break (as above) after "inter blocks", changing "which" to
"this", and changing "since" to "because". (This last is a personal
preference, but I think it sounds 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.




More information about the MPlayer-DOCS mailing list