[MPlayer-DOCS] CVS: main/DOCS/xml/en encoding-guide.xml, 1.32, 1.33

The Wanderer inverseparadox at comcast.net
Mon Nov 28 00:23:10 CET 2005


On 11/27/2005 02:48 PM, Guillaume Poirier CVS wrote:

> CVS change done by Guillaume Poirier CVS

> +  The following steps will guide you to compute the resolution of your
> +  encode without taking too much distortion by taking into account several
> +  information about the souce video.

"to compute" -> "in computing", but while the result would be mostly
grammatical I'm not sure it would be clear. I think what you mean is
"without distorting the video too much" (i.e., without losing much
quality), but the current phrasing does not seem to say that, and I'm
not entirely sure what would be a good fix. Also, the double use of the
word "taking" in close proximity is not a very good thing.

>  <para>
> -  The CQ depends both on the bitrate and the movie resolution.
> +  The CQ depends both on the bitrate, the video codec efficiency and the
> +  movie resolution.

Since you're no longer talking about just two things, you want "depends
on all of" or just "depends on".

>    In order to raise the CQ, typically you would downscale the movie given that the
>    bitrate is computed in function of the target size and the length of the
>    movie, which are constant.
> -  A CQ below 0.18 usually ends up in a very blocky picture, because there
> +  With MPEG-4 ASP codecs such as <systemitem class="library">XviD</systemitem>
> +  and <systemitem class="library">libavcodec</systemitem>, a CQ below 0.18
> +  usually ends up in a pretty blocky picture, because there

"ends up" -> "results"

(I'm thinking that I might need to go over this file and see what I can
fix, just on my own.)

>    are not enough bits to code the information of each macroblock (MPEG4, like
>    many other codecs, groups pixels by blocks of several pixels to compress the
>    image; if there are not enough bits, the edges of those blocks are
>    visible).

I'd add a period after "macroblock" and move the existing period back
one character, making the entire parenthetical comment its own (still
parenthetical) sentence. This is, of course, unrelated to your change.

>    It is therefore wise to take a CQ ranging from 0.20 to 0.22 for a 1 CD rip,
> -  and 0.26-0.28 for 2 CDs.
> +  and 0.26-0.28 for 2 CDs with standard encoding options.
> +  More advanced encoding options such as those listed here for
> +  <link linkend="menc-feat-mpeg4-lavc-example-settings"><systemitem class="library">libavcodec</systemitem></link>
> +  and
> +<link linkend="menc-feat-xvid-example-settings"><systemitem class="library">XviD</systemitem></link>
> +  should make it possible to get the same quality with CQ ranging from
> +  0.18 to 0.20 for 1 CD rip, and 0.24-0.26 for 2 CDs

"a 1 CD rip" or "1 CD rips" or even just "1 CD" - for both correct
plurality and, in some cases, parallelism with the "two" case.

>    On the other hand, it is worthless to raise CQ higher than 0.30 as you would
>    be wasting bits without any noticeable quality gain.
> +  Also note that as said earlier on this quide, low resolution comparatively
> +  need a bigger QP to look good.

"as said earlier on" -> "as mentioned earlier in" (or even "as described
earlier in")

...actually, there's something wrong with the entire sentence. There's
something strange about the tense of "need", and I'm not sure what is
meant here by "comparatively" at all - comparatively low resolution?
comparatively high QP? something else which I'm not quite finding words
for?

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.




More information about the MPlayer-DOCS mailing list