menc-feat-dvd-mpeg4.html

MPlayer-mingw32-1.0rc2.zip 经典播放器源码

quality at 1400 MB.
</p><p>
There are three approaches to encoding the video: constant bitrate
(CBR), constant quantizer, and multipass (ABR, or average bitrate).
</p><p>
The complexity of the frames of a movie, and thus the number of bits
required to compress them, can vary greatly from one scene to another.
Modern video encoders can adjust to these needs as they go and vary
the bitrate.
In simple modes such as CBR, however, the encoders do not know the
bitrate needs of future scenes and so cannot exceed the requested
average bitrate for long stretches of time.
More advanced modes, such as multipass encode, can take into account
the statistics from previous passes; this fixes the problem mentioned
above.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note:</h3><p>
Most codecs which support ABR encode only support two pass encode
while some others such as <code class="systemitem">x264</code>,
<code class="systemitem">Xvid</code>
and <code class="systemitem">libavcodec</code> support
multipass, which slightly improves quality at each pass,
yet this improvement is no longer measurable nor noticeable after the
4th or so pass.
Therefore, in this section, two pass and multipass will be used
interchangeably.
</p></div><p>
In each of these modes, the video codec (such as
<code class="systemitem">libavcodec</code>)
breaks the video frame into 16x16 pixel macroblocks and then applies a
quantizer to each macroblock. The lower the quantizer, the better the
quality and higher the bitrate.
The method the movie encoder uses to determine
which quantizer to use for a given macroblock varies and is highly
tunable. (This is an extreme over-simplification of the actual
process, but the basic concept is useful to understand.)
</p><p>
When you specify a constant bitrate, the video codec will encode the video,
discarding
detail as much as necessary and as little as possible in order to remain
lower than the given bitrate. If you truly do not care about file size,
you could as well use CBR and specify a bitrate of infinity. (In
practice, this means a value high enough so that it poses no limit, like
10000Kbit.) With no real restriction on bitrate, the result is that
the codec will use the lowest
possible quantizer for each macroblock (as specified by
<tt class="option">vqmin</tt> for 
<code class="systemitem">libavcodec</code>, which is 2 by default).
As soon as you specify a
low enough bitrate that the codec
is forced to use a higher quantizer, then you are almost certainly ruining
the quality of your video.
In order to avoid that, you should probably downscale your video, according
to the method described later on in this guide.
In general, you should avoid CBR altogether if you care about quality.
</p><p>
With constant quantizer, the codec uses the same quantizer, as
specified by the <tt class="option">vqscale</tt> option (for
<code class="systemitem">libavcodec</code>), on every macroblock.
If you want the highest quality rip possible, again ignoring bitrate,
you can use <tt class="option">vqscale=2</tt>.
This will yield the same bitrate and PSNR (peak signal-to-noise ratio)
as CBR with
<tt class="option">vbitrate</tt>=infinity and the default <tt class="option">vqmin</tt>
of 2.
</p><p>
The problem with constant quantizing is that it uses the given quantizer
whether the macroblock needs it or not. That is, it might be possible
to use a higher quantizer on a macroblock without sacrificing visual
quality. Why waste the bits on an unnecessarily low quantizer? Your
CPU has as many cycles as there is time, but there is only so many bits
on your hard disk.
</p><p>
With a two pass encode, the first pass will rip the movie as though it
were CBR, but it will keep a log of properties for each frame. This
data is then used during the second pass in order to make intelligent
decisions about which quantizers to use. During fast action or high
detail scenes, higher quantizers will likely be used, and during
slow moving or low detail scenes, lower quantizers will be used.
Normally, the amount of motion is much more important than the
amount of detail.
</p><p>
If you use <tt class="option">vqscale=2</tt>, then you are wasting bits. If you
use <tt class="option">vqscale=3</tt>, then you are not getting the highest
quality rip. Suppose you rip a DVD at <tt class="option">vqscale=3</tt>, and
the result is 1800Kbit. If you do a two pass encode with
<tt class="option">vbitrate=1800</tt>, the resulting video will have
<span class="bold"><strong>higher quality</strong></span> for the
<span class="bold"><strong>same bitrate</strong></span>.
</p><p>
Since you are now convinced that two pass is the way to go, the real
question now is what bitrate to use? The answer is that there is no
single answer. Ideally you want to choose a bitrate that yields the
best balance between quality and file size. This is going to vary
depending on the source video.
</p><p>
If size does not matter, a good starting point for a very high quality
rip is about 2000Kbit plus or minus 200Kbit.
For fast action or high detail source video, or if you just have a very
critical eye, you might decide on 2400 or 2600.
For some DVDs, you might not notice a difference at 1400Kbit. It is a
good idea to experiment with scenes at different bitrates to get a feel.
</p><p>
If you aim at a certain size, you will have to somehow calculate the bitrate.
But before that, you need to know how much space you should reserve for the
audio track(s), so you should
<a class="link" href="menc-feat-dvd-mpeg4.html#menc-feat-dvd-mpeg4-audio" title="14.1.11.聽Audio">rip those</a> first.
You can compute the bitrate with the following equation:
<code class="systemitem">bitrate = (target_size_in_Mbytes - sound_size_in_Mbytes) *
1024 * 1024 / length_in_secs * 8 / 1000</code>
For instance, to squeeze a two-hour movie onto a 702MB CD, with 60MB
of audio track, the video bitrate will have to be:
<code class="systemitem">(702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000
= 740kbps</code>
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="menc-feat-dvd-mpeg4-constraints"></a>14.1.3.聽Constraints for efficient encoding</h3></div></div></div><p>
Due to the nature of MPEG-type compression, there are various
constraints you should follow for maximal quality.
MPEG splits the video up into 16x16 squares called macroblocks,
each composed of 4 8x8 blocks of luma (intensity) information and two
half-resolution 8x8 chroma (color) blocks (one for red-cyan axis and
the other for the blue-yellow axis).
Even if your movie width and height are not multiples of 16, the
encoder will use enough 16x16 macroblocks to cover the whole picture
area, and the extra space will go to waste.
So in the interests of maximizing quality at a fixed filesize, it is
a bad idea to use dimensions that are not multiples of 16.
</p><p>
Most DVDs also have some degree of black borders at the edges. Leaving
these in place will hurt quality <span class="bold"><strong>a lot</strong></span>
in several ways.
</p><div class="orderedlist"><ol type="1"><li><p>
  MPEG-type compression is highly dependent on frequency domain
  transformations, in particular the Discrete Cosine Transform (DCT),
  which is similar to the Fourier transform. This sort of encoding is
  efficient for representing patterns and smooth transitions, but it
  has a hard time with sharp edges. In order to encode them it must
  use many more bits, or else an artifact known as ringing will
  appear.
  </p><p>
  The frequency transform (DCT) takes place separately on each
  macroblock (actually each block), so this problem only applies when
  the sharp edge is inside a block. If your black borders begin
  exactly at multiple-of-16 pixel boundaries, this is not a problem.
  However, the black borders on DVDs rarely come nicely aligned, so
  in practice you will always need to crop to avoid this penalty.
  </p></li></ol></div><p>
In addition to frequency domain transforms, MPEG-type compression uses
motion vectors to represent the change from one frame to the next.
Motion vectors naturally work much less efficiently for new content
coming in from the edges of the picture, because it is not present in
the previous frame. As long as the picture extends all the way to the
edge of the encoded region, motion vectors have no problem with
content moving out the edges of the picture. However, in the presence
of black borders, there can be trouble:
</p><div class="orderedlist"><ol start="2" type="1"><li><p>
  For each macroblock, MPEG-type compression stores a vector
  identifying which part of the previous frame should be copied into
  this macroblock as a base for predicting the next frame. Only the
  remaining differences need to be encoded. If a macroblock spans the
  edge of the picture and contains part of the black border, then
  motion vectors from other parts of the picture will overwrite the
  black border. This means that lots of bits must be spent either
  re-blackening the border that was overwritten, or (more likely) a
  motion vector will not be used at all and all the changes in this
  macroblock will have to be coded explicitly. Either way, encoding
  efficiency is greatly reduced.
  </p><p>
  Again, this problem only applies if black borders do not line up on
  multiple-of-16 boundaries.
  </p></li><li><p>
  Finally, suppose we have a macroblock in the interior of the
  picture, and an object is moving into this block from near the edge
  of the image. MPEG-type coding cannot say "copy the part that is
  inside the picture but not the black border." So the black border
  will get copied inside too, and lots of bits will have to be spent
  encoding the part of the picture that is supposed to be there.
  </p><p>
  If the picture runs all the way to the edge of the encoded area,
  MPEG has special optimizations to repeatedly copy the pixels at the
  edge of the picture when a motion vector comes from outside the
  encoded area. This feature becomes useless when the movie has black
  borders. Unlike problems 1 and 2, aligning the borders at multiples
  of 16 does not help here.
  </p></li><li><p>
  Despite the borders being entirely black and never changing, there
  is at least a minimal amount of overhead involved in having more
  macroblocks.
</p></li></ol></div><p>
For all of these reasons, it is recommended to fully crop black
borders. Further, if there is an area of noise/distortion at the edge
of the picture, cropping this will improve encoding efficiency as
well. Videophile purists who want to preserve the original as close as
possible may object to this cropping, but unless you plan to encode at
constant quantizer, the quality you gain from cropping will
considerably exceed the amount of information lost at the edges.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="menc-feat-dvd-mpeg4-crop"></a>14.1.4.聽Cropping and Scaling</h3></div></div></div><p>
Recall from the previous section that the final picture size you
encode should be a multiple of 16 (in both width and height).
This can be achieved by cropping, scaling, or a combination of both.
</p><p>
When cropping, there are a few guidelines that must be followed to
avoid damaging your movie.
The normal YUV format, 4:2:0, stores chroma (color) information
subsampled, i.e. chroma is only sampled half as often in each
direction as luma (intensity) information.
Observe this diagram, where L indicates luma sampling points and C
chroma.
</p><div class="informaltable"><table border="1" width="40%"><colgroup><col align="center"><col align="center"><col align="center"><col align="center"><col align="center"><col align="center"><col align="center"><col align="center"></colgroup><tbody><tr><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td></tr><tr><td colspan="2" align="center">C</td><td colspan="2" align="center">C</td><td colspan="2" align="center">C</td><td colspan="2" align="center">C</td></tr><tr><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td></tr><tr><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td></tr><tr><td colspan="2" align="center">C</td><td colspan="2" align="center">C</td><td colspan="2" align="center">C</td><td colspan="2" align="center">C</td></tr><tr><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td><td align="center">L</td></tr></tbody></table></div><p>
As you can see, rows and columns of the image naturally come in pairs.
Thus your crop offsets and dimensions <span class="emphasis"><em>must</em></span> be
even numbers.