[MPlayer-cvslog] CVS: main/DOCS/tech swscaler_methods.txt, 1.1, 1.2

[The Wanderer]

Guillaume Poirier CVS wrote:

> CVS change done by Guillaume Poirier CVS
> 
> Update of /cvsroot/mplayer/main/DOCS/tech
> In directory mail:/var2/tmp/cvs-serv12394/DOCS/tech
> 
> Modified Files:
> 	swscaler_methods.txt 
> Log Message:
> Typo :)

But a couple of things still slipped through:

>  note: when encoding at a limited amount of bits (not constant quantizer) 
> -than a slightly blured input might look better after decoding than a slightly 
> +then a slightly blured input might look better after decoding than a slightly 
>  sharpend one, especially for lower bitrates

"blurred", "sharpened"

Also: I would say either "When encoding" ... "quantizer) a slightly" et
cetera, or "If you are encoding" ... "quantizer) then a slightly" et
cetera. I'm not sure which, if either, would be better, but the current
form doesn't work quite right.

I'm not entirely happy with the construction "amount of bits", but I'm
not sure how to fix it without introducing other problems.


There are also a number of other typographical/etc. errors in that file
(if I'd realized that there were any files left with that many problems,
I'd have gone hunting them down long since), and I've got a fix for most
of them handy - but there's one thing I'm not certain about. Further up
in the file, in the section on types of artifacting, the "blur"
description line reads: "loss of detail / high frequency". As best I
understand it, this either means that one of the possible things which
is considered to be a "blur" artifact is "high frequency" - and that
this is bad (and I don't know how high frequency can automatically be
considered bad) - or that high frequency *something* is lost.. but
neither of these makes much sense to me, and I don't know what was
intended. Since I don't understand what was meant here, it probably
needs to be rephrased; does anyone know what was actually meant?

(While I'm at this: there is at least one place in that file where there
is a line which is entirely blank except for roughly a tab-width of
spaces. I can understand such being useful for cursor-positioning
convenience in actual source code, but it doesn't seem to serve any
purpose here, especially since nothing in the file is directly indented;
would it be acceptable to remove those useless spaces, in the name of
reducing filesize slightly?)

(And, on loosely the same subject, there are several lines on which
there are trailing spaces which serve no obvious function; I'd be
inclined to remove them as well, unless someone objects.)

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