[MPlayer-DOCS] [PATCH] improving encoding guide

[The Wanderer]

Guillaume POIRIER wrote:

> Hi,
> 
> Le mardi 15 mars 2005 à 22:56 +0100, Guillaume Poirier a écrit :
> 
>> Here's an updated version. It contains more things than previous
>> version.
>> 
>> I'm now looking for people with some language knowledge, (such as
>> The Wonderer, who has been of a great help for me this summer)

Nice typo... it's not my name, but I'll admit I do a good bit of that.

I might actually have gotten around to this sooner if I'd noticed this
comment specifically... for some while now, I've been mostly almost
skimming the mailing lists, sometimes barely reading each message.

> Use a spellchecker, Luke...
> 
> Here's the same patch spell-checked.
> Any comments are very welcome!

(After writing the below:)

Phew! Quite a bit more than I expected there to be. Hopefully this is
helpful, rather than being unnecessarily nitpicky...

> -  This question is perhaps at least somewhat wrongly posed. After all, if
> +  The later question is perhaps at least somewhat wrongly posed. After all, if
>    you don't care about file size, why not simply copy the MPEG-2 video
>    stream from the DVD whole? Sure, your AVI will end up being 5GB, give
>    or take, but if you want the best quality and don't care about size,

"latter"

The word "whole" is at best misplaced - I'd suggest something like "the
entire MPEG-2 video stream".

> +  If this seems to be too much for you, you should probably use one of the
> +  many fine front-ends that are listed on our
> +  <ulink url="http://mplayerhq.hu/homepage/design7/projects.html">related projects page</ulink>.
> +  That way, you should be able to achieve high quality rips without too much
> +  thinking as most of those tools are designed to take clever decisions for
> +  you.

Comma after "thinking", and possibly switch "as" for "because".
Alternately, you could drop "as" and use a semicolon instead of a comma.

> @@ -590,8 +591,10 @@
>    <option>vqmin</option>, which is 2 by default). As soon as you specify a
>    low enough bitrate that <systemitem class="library">libavcodec</systemitem>
>    is forced to use a higher quantizer, then you're almost certainly ruining
> -  the quality of your video. In general, you should avoid CBR altogether if
> -  you care about quality.
> +  the quality of your video.
> +  In order to avoid that, you should probably down-scale your video, according
> +  to the method that will be exposed later.
> +  In general, you should avoid CBR altogether if you care about quality.

I don't understand what "the method that will be exposed later" means.
(I also prefer "which" to "that" in such contexts, but others say
they're equivalent.)

> +  If you aim a certain size, you will have to somehow calculate the bitrate.

"aim for" or "aim at"

> +  But before that, you should have a ripped the
> +  <link linkend="menc-feat-dvd-mpeg4-audio">audio track(s)</link>, in
> +  order to know how much space you should reserve.

"should have a ripped" - drop the "a".

Need to somehow indicate 'reserve for what' - simply saying "reserve for
those" is a little awkward, but works; "reserve for the audio" is
repetition, but less awkward otherwise.

Possibly "But before that, you need to know how much space you should
reserve for the audio track(s), so you should rip those first."? Trouble
there is that I don't see any obvious place to put the audio-encoding
link.

> +  You can compute the bitrate with the following equation:
> +  bitrate = (target_size_in_Mbytes - sound_size_in_Mbytes) * 1024 * 1024 / length_in_secs * 8 / 1000
> +  For instance, to squeeze into a 702Mbytes CD a 2 hour movie, with 60Mbytes
> +  of audio track, the video bitrate will have to be
> +  (702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000 = 740kbps.

"squeeze a two-hour movie into a 702Mbyte CD, with"

> +  You can actually let the <option>cropdetect</option> filter do all of the
> +  above for you as it has an optional <option>round</option> parameter that
> +  is equal to 16 by default.

Again, as above with "thinking", a comma or semicolon split before the
word "as".

> -  that will do this for you. Absolutely do not scale this video in order to
> +  that will do this for you. Absolutely do not upscale this video in order to

"scale this video up"

> +  First, you should compute the encoded aspect ratio:
> +  ARc = (Wc x (ARa / PRdvd )) / Hc
> +<itemizedlist>
> +<title>where:</title>
> +<listitem><para>
> +  Wc are Hc are the width and height of the cropped video,

"Wc and Hc are", I think you mean?

> +<para>
> +  Okay, but what is the CQ?
> +  The CQ represents the amount of bits per pixel and per frame of the encode.

Probably better to say "number" than "amount".

> +  Roughly speaking, the greater the CQ, the less the likelihood to see
> +  encoding artefacts.

AFAIK, "artefacts" is either a Britishism or simply archaic; "artifacts"
is the standard spelling.

> +  However, if you have a target size for your movie (1 or 2 CDs for instance),
> +  there's a finite total amount of bits that you can spend, therefore it's
> +  necessary to find a good tradeoff between compressibility and quality.

Suggest "limited" instead of "finite", and "total number" instead of
"total amount" (as above).

You need to either split the sentence before the word "therefore"
(period or semicolon), or replace "therefore" with "so". (I think it's
grammatically valid as it stands, but it doesn't sound right anyway.)

> +  A CQ below 0.18 usually ends up in a very blocky picture, for there aren't
> +  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, therefore if there aren't enough bits, the edge of those blocks are
> +  visible).

"because there aren't"

I'd suggest splitting with a semicolon after "compress the image", and
dropping the word "therefore". This is mainly though not exclusively to
avoid the use of too many commas in too small a space.

> +  Beware, the CQ is just an indicative figure, as depending on the encoded
> +  content, a CQ of 0.18 may look just fine for a Bergman, contrary to a movie
> +  such as Matrix, which contains many high-motion scenes.

I don't know if I'm happy with "beware", as opposed to something like
"Remember that" or "Take note:". Also, the name of the movie is "The
Matrix"; whether you separate the name out with quotation marks or the
like or simply capitalize both words is up to you, but you need to
include the definite article.

> +  You can also extract the AC3 stream in order to mux it into containers such
> +  as Nut, Matroska or OGM.

This is a minor point: the NUT standard does not yet appear to specify
what the correct capitalization is. Some places in what documentation
there is (both in FFmpeg and in MPlayer) use "NUT", others "Nut", and I
think a few even use "nut". I don't know what the 'correct' form is,
since as I said it doesn't appear to have been specified anywhere;
however, I've seen recent commits using NUT, and it would be nice if we
could standardize on a single form.

> +  But sometimes you truly don't have the choice but to further compress the
> +  sound so that more bits can be spent on the video.

"don't have any choice" or "have no choice"

> +  Most people use the audio codecs MP3 or Ogg Vorbis.

I'm not entirely sure why, but this (following "audio codecs"
immediately with the examples) is slightly nonstandard. A possible
alternative would be "Most people choose to compress audio with either
MP3 or Ogg Vorbis"; that doesn't mention "codecs" specifically, but I
think is less awkward than what we had.

> +  While the latter is a very space-efficient codec, MP3 is better supported
> +  by hardware players, but this trend is changing.

"although" instead of "but"

> +<para>
> +  First of all, you will have to convert the DVD sound into a wav file that the
> +  audio codec supports.

Two points: one, I'm not entirely certain that that shouldn't be "WAV",
although it certainly isn't an acronym AFAIK. Two, I'd suggest "that the
audio codec can use as input", since it sounds slightly nonsensical to
say that a codec "supports" any other format. (It probably isn't, but it
sounds that way to me at first glance.)

> +  For example:
> +  <screen>mplayer source_file.vob -ao pcm:file=destination_sound.wav -vc dummy -aid 1 -vo null</screen>
> +  will dump into the file destination_sound.wav the second audio track from
> +  the file source_file.vob.

Switch the order of the parts of this sentence - "dump the second audio
track from the file source_file.vob into the file destination_sound.wav".

> +  You may want to normalize the sound before encoding, as DVD audio tracks
> +  are recorded at low volumes.

Are they always? If not, insert "frequently" or "often" or "commonly"
before "recorded".

> +  You can use the tool "normalize" that is available as a package in every
> +  distribution.

I don't think it's likely that absolutely *every* distribution provides
a normalize package, although most almost certainly do; I have this sort
of general notion that not every distribution even provides packages. In
any case, this isn't going to be helpful to people who don't run an
*nix; don't forget that MPlayer is also available for Windows.

On a separate note, shouldn't the program name 'normalize' be contained
in a set of tags to indicate that it is a program name? (<application>,
or the like.)

> +  You will then either compress in Ogg Vorbis or MP3.

"compress in either Ogg Vorbis or MP3" or "compress either in Ogg Vorbis 
or in MP3"

> +  For example:
> +  <screen>oggenc -q1 destination_sound.wav</screen>
> +  will encode destination_sound.wav with the encoding quality 1, which is
> +  somewhat equivalent to 80Kb/s, and is the minimum quality at which you
> +  should encode if you care about quality.

"somewhat" > "roughly"

The use of "at which you should" is the grammatically correct form,
since the alternative is to end a sentence segment with a preposition,
and I'm not going to recommend changing it - but it is also not standard
everyday usage, and as such feels a little awkward. As I said, that's
because standard usage is incorrect, but I felt the point might be worth
mentioning.

> +  Please note that MEncoder currently can't currently mux Ogg Vorbis files
> +  into a video stream as it can only create AVI and MPEG files.
> +  Don't worry, this document will should you how you can do that with third
> +  party programs.
> +</para>

Comma after "as", and (as above) possibly replace "as" with "because".

What word did you want which is now given as "should"? "show", perhaps?

> +  Ideally, you'd probably want to be able to just tell the encoder to switch
> +  in "high quality" mode and move on.

"switch in" - did you want "switch into", or "switch on", or something
else? The latter makes more sense, but leads to repetition of "on".

> +  That would probably be nice, but unfortunately hard to implement as different
> +  encoding options yield different qualities depending on the source material.
> +  Anime and live action are for example two very different materials that
> +  require different care.

"different care" seems a little odd to me, but I've got no suggestions
to improve it, and I'm not completely certain that it needs to be
changed at all.

> +  The good news are that some options should never be left out, like
> +  <option>mbd=2</option>, <option>trell</option>, and <option>v4mv</option>.
> +  See below a detailed description of common encoding options. 

"good news is"

> +<title>Options to ajust:</title>

"adjust" - how this one slipped past the spellchecker I don't know.

> +<listitem><para>
> +  <emphasis role="bold">vmax_b_frames</emphasis>: 1 or 2 is good, depending on
> +  the movie.
> +  Note that lavc does not yet support closed GOP (the option
> +  <option>cgop</option> doesn't currently work), so DivX5 won't be able to
> +  decode anything encoded with B-frames.

Sure you want "lavc" here instead of "libavcodec"?

> +<listitem><para>
> +  <emphasis role="bold">cmp, subcmp, precmp</emphasis>: Comparison function of
> +  motion estimation.

"of" > "for" ?

> +<listitem><para>
> +  <emphasis role="bold">last_pred</emphasis>: Amount of motion predictors to
> +  take from the previous frame.

Again, "amount" might not be the right word to use.

> +<listitem><para>
> +  <emphasis role="bold">qprd</emphasis>: adaptive quantization based on the
> +  macroblock's complexity.
> +  May help or hurt depending on the video and other options.
> +  This can cause artifacts unless you set vqmax to some reasonably small value
> +  (6 is good, maybe as low as 4), and vqmin=1 should also help.

Replace the ", and" with a semicolon.

> +<listitem><para>
> +  <emphasis role="bold">qns</emphasis>: very slow, especially when combined
> +  with qprd.
> +  Don't use this until you've turned everything else to max.

I think that you mean something like "Don't use this unless you've
already tweaked everything else as far as it will go and the results
stll aren't good enough". If so, a more explicit statement to that
effect might be helpful.

> +<listitem><para>
> +  <emphasis role="bold">vqcomp</emphasis>: Tweak ratecontrol.
> +  Good values depend on the movie.

"What values are good depends on the movie", might be better - it's
still awkward, but means what you want it to without depending on
out-of-sentence context.

> +<listitem><para>
> +  <emphasis role="bold">vlelim, vcelim</emphasis>: Sets the single coefficient
> +  elimination threshold for luminance chroma planes.

I could be remembering wrong, but aren't luminance and chroma different
things? If so, you probably accidentally omitted the word "and" in the
middle there.

> +  These are encoded separately in all mpeg-like algorithms.

Should "mpeg" be lowercase here, or not?

> +  The idea behind these options is to use some good heuristics to determine
> +  when the change in a block is less than the threshold you specify, and in
> +  such a case, to just  encode the block as "no change".
> +  This saves bits and perhaps speeds up encoding. vlelim=-4 and vcelim=9
> +  seem to be good for live movies, but seem not to help in with anime, in which
> +  case, leave it as it is.

"with anime; when encoding animation, you should probably leave them
unchanged", I think.

> +<listitem><para>
> +  <emphasis role="bold">qpel</emphasis>: Quarter pixel motion estimation.
> +  MPEG-4 uses a half pixel precision for its motion search by default,
> +  therefore this option comes with an overhead as more informations will be
> +  stored in the encoded file.

"information" - singular.

> +  The compression gain/loss depends on the movie, but it's usually not very
> +  effective on anime.
> +  Qpel always incurs a significant cost in CPU time needed to decode (+20% in
> +  practice).

I might argue that "qpel" should not be capitalized, but because it's a
term in addition to being a command-line option, I won't be as adamant
about it as I am about correctly capitalizing things like "eBay" and "e.
e. cummings" and so forth.

> +</para></listitem>
> +
> +<listitem><para>
> +  <emphasis role="bold">psnr</emphasis>: doesn't affect the actual encoding,
> +  but writes a log file giving the type/size/quality of each frame, and
> +  summarizes psnr at the end.

"prints a sumary of", perhaps?

It might be worthwhile to explain what PSNR stands for, since not
everyone is necessarily going to know that, and it isn't trivial to
figure out from context. (I got it, but I'm good with acronyms.)

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