[MPlayer-DOCS] [PATCH] Preparing to encode: Identifying source material and framerate
Guillaume POIRIER
poirierg at gmail.com
Sat May 14 00:58:53 CEST 2005
Hi,
On 5/14/05, Jeff Clagg <snacky at ikaruga.co.uk> wrote:
> On Fri, May 13, 2005 at 07:25:57AM +0200, Guillaume POIRIER wrote:
> > On 5/13/05, Loren Merritt <lorenm at u.washington.edu> wrote:
> > > On Thu, 12 May 2005, Jeff Clagg wrote:
> > > > On Thu, May 12, 2005 at 09:22:35PM +0200, Guillaume POIRIER wrote:
> > > >
> > > >> + Failure to take this into account will result in ugly combing
> > > >> + (interlacing) artifacts in your encode, and will greatly reduce the
> > > >> + quality/bitrate ratio of the encoder!
> > > >
> > > > quality/bitrate of the encode
> > > > (or something similar)
> > >
> > > IMHO, either keep "ratio" or make it "quality per bitrate". In a
> > > mathematical context, "quality/bitrate" is enough, but in an English
> > > sentence the "/" could be construed as meaning "or".
> >
> > Ok, I settled for "quality per bitrate ratio of the encoder". Fixed
> > locally. Thanks!
>
> This addresses Loren's point but not mine - the thing we're talking
> about isn't the encodER, it's the encode. But how about I suggest a
> complete rewrite of the sentence that also addresses both issues:
>
> "Failure to take this into account will result in ugly combing
> (interlacing) artifacts in your encode. Besides being ugly, the
> artifacts also harm coding efficiency: you will get worse quality per
> bitrate."
Yep. Good suggestion. fixed locally and committed along with Diego's
suggestions in just a minute.
Guillaume
More information about the MPlayer-DOCS
mailing list