[FFmpeg-cvslog] r21062 - trunk/libavcodec/h263.c
Diego Biurrun
diego
Fri Jan 8 01:38:24 CET 2010
On Fri, Jan 08, 2010 at 01:11:58AM +0100, Michael Niedermayer wrote:
> On Thu, Jan 07, 2010 at 10:46:17PM +0100, Diego Biurrun wrote:
> > On Thu, Jan 07, 2010 at 04:31:54PM +0100, michael wrote:
> > >
> > > Log:
> > > Move restore_ac_coeffs() call into decode_ac_pred(), this makes later behave
> > > more understandable.
> >
> > I assume you meant "behavior" there?
>
> I meant that the second function behaves more understandable after the patch.
> I see nothing wrong with what i wrote though, am i missing something?
You said (grammar mistakes more or less conserved)
Verschiebe den Aufruf von restore_ac_coeffs() in decode_ac_pred(),
das macht sp?ter verh?lt sich einfacher zu verstehen.
from which I guessed
Verschiebe den Aufruf von restore_ac_coeffs() in decode_ac_pred(),
das macht sp?teres Verhalten einfacher zu verstehen.
instead of
Verschiebe den Aufruf von restore_ac_coeffs() in decode_ac_pred(),
das macht letztere Funktion einfacher zu verstehen.
Be careful, English has a very low Hamming distance between words:
later == sp?ter
(the) latter == letztere[rs]
You make this mistake quite often and unfortunately it has this
propensity to create confusion, as it did now.
I fixed the message:
Move restore_ac_coeffs() call into decode_ac_pred().
This makes the latter function easier to understand.
But probably
Move restore_ac_coeffs() call into decode_ac_pred().
This makes decode_ac_pred() easier to understand.
is both simpler to write and easier to understand.
So you see, writing good prose can be a lot like writing good code.
My last variant is (arguably) the simplest possible way to express
the thought :)
Diego
More information about the ffmpeg-cvslog
mailing list