# HG changeset patch
# User gpoirier
# Date 1115055923 0
# Node ID f351dd913bc6c5b461e2eb809adec518d14d987c
# Parent 5bd11a72dc58ed314d321fa745801412804f2391
x264's encoding and install guide
Based on Jeff Clagg's "preliminary x264 encoding help text"
diff -r 5bd11a72dc58 -r f351dd913bc6 DOCS/xml/en/codecs.xml
--- a/DOCS/xml/en/codecs.xml Mon May 02 14:40:16 2005 +0000
+++ b/DOCS/xml/en/codecs.xml Mon May 02 17:45:23 2005 +0000
@@ -531,6 +531,149 @@
+
+
+x264
+
+
+What is x264?
+
+ x264 is a library for
+ creating H.264 video streams.
+ It is not 100% complete, but currently it has at least some kind
+ of support for most of the H.264 features which impact quality.
+ There are also many advanced features in the H.264 specification
+ which have nothing to do with video quality per se; many of these
+ are not yet implemented in
+ x264.
+
+
+
+Encoder features
+ CAVLC/CABAC
+ Multi-references
+ Intra: all macroblock types (16x16 and 4x4 with
+ all predictions)
+ Inter P: all partitions (from 16x16 down to
+ 4x4)
+ Inter B: partitions from 16x16 down to 8x8
+ (including SKIP/DIRECT)
+ Ratecontrol: constant quantizer, constant bitrate,
+ or multipass ABR
+ Scene cut detection
+ Adaptive B-frame placement
+ B-frames as references / arbitrary frame
+ order
+
+
+
+Encoder limitations
+ No real RD
+
+
+
+
+
+
+What is H.264?
+
+ H.264 is one name for a new digital video codec jointly developed
+ by the ITU and MPEG.
+ It can also be correctly referred to by the cumbersome names of
+ "ISO/IEC 14496-10" or "MPEG-4 Part 10".
+ More frequently, it is referred to as "MPEG-4 AVC" or just "AVC".
+
+
+ Whatever you call it, H.264 may be worth trying because it can
+ typically match the quality of MPEG-4 ASP with 5%-30% less
+ bitrate.
+ Actual results will depend on both the source material and the
+ encoder.
+ The gains from using H.264 do not come for free: decoding H.264
+ streams seems to have steep CPU and memory requirements.
+ For instance, on a 1733 MHz Athlon, a 1500kbps H.264 video uses
+ around 50% CPU to decode.
+ By comparison, decoding a 1500kbps MPEG4-ASP stream requires
+ around 10% CPU.
+ This means that decoding high-definition streams is almost out of
+ the question for most users.
+ It also means that even a decent DVD rip may sometimes stutter on
+ processors slower than 2.0 GHz or so.
+
+
+ At least with x264,
+ encoding requirements are not much worse than what you are used to
+ with MPEG4-ASP.
+ For instance, on a 1733 MHz Athlon a typical DVD encode would run
+ at 5-15fps.
+
+
+ This document is not intended to explain the details of H.264,
+ but if you are interested in a brief overview, you may want to read
+ The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions.
+
+
+
+
+How can I play H.264 videos with <application>MPlayer</application>?
+
+ MPlayer uses
+ libavcodec's H.264
+ decoder.
+ libavcodec has had at
+ least minimally usable H.264 decoding since around July 2004,
+ however major changes and improvements have been implemented since
+ that time, both in terms of more functionalities supported and in
+ terms of improved CPU usage.
+ Just to be certain, it is always a good idea to use a recent CVS
+ checkout.
+
+
+ If you want a quick and easy way to know whether there have been
+ recent changes to libavcodec's
+ H.264 decoding, you might keep an eye on
+ FFmpeg CVS repository's web interface.
+
+
+
+
+How can I encode videos using <application>MEncoder</application> and <systemitem class="library">x264</systemitem>?
+
+ If you have the subversion client installed, the latest x264
+ sources can be gotten with this command:
+
+ svn co svn://svn.videolan.org/x264/trunk x264
+
+ MPlayer sources are updated whenever
+ an x264 API change
+ occurs, so it is always suggested to use CVS
+ MPlayer as well.
+ Perhaps this situation will change when and if an
+ x264 "release" occurs.
+ Meanwhile, x264 should
+ be considered very unstable, in the sense that its programming
+ interface is subject to change.
+
+
+ x264 is built and
+ installed in the standard way:
+
+ ./configure && make && sudo make install
+
+ This installs libx264.a in /usr/local/lib and x264.h is placed in
+ /usr/local/include.
+
+ With the x264 library
+ and header placed in the standard locations, building
+ MPlayer with
+ x264 support is easy.
+ Just run the standard:
+ ./configure && make && sudo make install
+ The configure script will autodetect that you have satisfied the
+ requirements for x264.
+
+
+
diff -r 5bd11a72dc58 -r f351dd913bc6 DOCS/xml/en/mencoder.xml
--- a/DOCS/xml/en/mencoder.xml Mon May 02 14:40:16 2005 +0000
+++ b/DOCS/xml/en/mencoder.xml Mon May 02 17:45:23 2005 +0000
@@ -1806,6 +1806,306 @@
+
+Encoding with the <systemitem class="library">x264</systemitem> codec
+
+ x264 is a free library for
+ encoding H264/AVC video streams.
+ Before starting to encode, you need to
+ set up MEncoder to support it.
+
+
+
+What options should I use to get the best results?
+
+
+ Please begin by reviewing the
+ x264 section of
+ MPlayer's man page.
+ This section is intended to be a supplement to the man page.
+
+
+
+There are mainly three types of considerations when choosing encoding
+ options:
+ Trading off encoding time vs. quality
+ Frame type decision options
+ Ratecontrol and quantization decision options
+
+
+
+ This guide is mostly concerned with the first class of options.
+ The other two types often have more to do with personal
+ preferences and individual requirements.
+
+
+
+ Before continuing, please note that this guide uses only one
+ quality metric: global PSNR.
+ For a brief explanation of what PSNR is, see
+ the Wikipedia article on PSNR.
+ Global PSNR is the last PSNR number reported when you include
+ the option in .
+ Any time you will read a claim about PSNR, one of the assumptions
+ behind the claim is that equal bitrates are used.
+
+
+
+ Nearly all of this guide's comments assume you are using
+ two pass.
+ When comparing options, there are two major reasons for using
+ two pass encoding.
+ First, using two pass often gains around 1dB PSNR, which is a
+ very big difference.
+ Secondly, testing options by doing direct quality comparisons
+ with 1-pass encodes is a dubious proposition because bitrate
+ often varies significantly with each encode.
+ It is not always easy to tell whether quality changes are due
+ mainly to changed options, or if they mostly reflect
+ differences in the achieved bitrate.
+
+
+
+ Of the options which allow you to trade off speed for quality,
+ and are usually
+ by far the most important.
+ If you are interested in tweaking either speed or quality, these
+ are the first options you should consider.
+
+
+
+ On the speed dimension, the and
+ options interact with each other fairly
+ strongly.
+ Experience shows that, with one reference frame,
+ takes about 35% more time than
+ .
+ With 6 reference frames, the penalty grows to over 60%.
+ 's effect on PSNR seems fairly constant
+ regardless of the number of reference frames.
+ Typically, gains 0.2-0.5 dB
+ global PSNR over .
+ This is usually enough to be visible.
+
+
+
+
+
+Encoding options of x264
+
+
+
+ frameref:
+ is set to 1 by default, but this
+ should not be taken to imply that it is reasonable to set it
+ to 1.
+ Merely raising to 2 gains around
+ 0.15dB PSNR with a 5-10% speed penalty; this seems like a
+ good tradeoff.
+ gains around 0.25dB PSNR over
+ , which should be a visible
+ difference.
+ is around 15% slower than
+ .
+ Unfortunately, diminishing returns set in rapidly.
+ can be expected to gain only
+ 0.05-0.1 dB over at an additional
+ 15% speed penalty.
+ Above , the quality gains are
+ usually very small (although you should keep in mind throughout
+ this whole discussion that it can vary quite a lot depending on
+ your source).
+ In a fairly typical case,
+ will improve global PSNR by a tiny 0.02dB over
+ , at a speed cost of 15%-20%.
+ At such high values, the only really
+ good thing that can be said is that increasing even further will
+ almost certainly never harm
+ PSNR, but the additional quality benefits are barely even
+ measurable, let alone perceptible.
+
+Note:
+
+ Raising to unnecessarily high values
+ can and
+ usually does
+ hurt coding efficiency if you turn CABAC off.
+ With CABAC on (the default behavior), the possibility of setting
+ "too high" currently seems too remote
+ to even worry about, and in the future, optimizations may remove
+ the possibility altogether).
+
+
+
+ If you care about speed, a reasonable compromise is to use low
+ and values on
+ the first pass, and then raise them on the second pass.
+ Typically, this has a negligible negative effect on the final
+ quality: you will probably lose well under 0.1dB PSNR, which
+ should be much too small of a difference to see.
+ However, different values of can
+ occasionally affect frametype decision.
+ Most likely, these are rare outlying cases, but if you want to
+ be pretty sure, consider whether your video has either
+ fullscreen repetitive flashing patterns or very large temporary
+ occlusions which might force an I-frame.
+ Adjust the first-pass so it is large
+ enough to contain the duration of the flashing cycle (or occlusion).
+ For example, if the scene flashes back and forth between two images
+ over a duration of three frames, set the first pass
+ to 3 or higher.
+ This issue is probably extremely rare in live action video material,
+ but it does sometimes come up in video game captures.
+
+
+
+ bframes:
+ The usefulness of B-frames is questionable in most other codecs
+ you may be used to.
+ In H.264, this has changed: there are new techniques and block
+ types that are possible in B-frames.
+ Usually, even a naive B-frame choice algorithm can have a
+ significant PSNR benefit.
+ It is also interesting to note that if you turn off the adaptive
+ B-frame decision (), encoding with
+ usually speeds up encoding speed somewhat.
+
+
+ With adaptive B-frame decision turned off
+ ('s ),
+ the optimal value for this setting will usually range from
+ to .
+ With adaptive B-frame decision on (the default behavior), it is
+ probably safe to use higher values; the encoder will try to
+ reduce the use of B-frames in scenes where they would hurt
+ compression.
+
+
+ If you are going to use at all, consider
+ setting the maximum number of B-frames to 2 or higher in order to
+ take advantage of weighted prediction.
+
+
+
+ b_adapt:
+ Note: this is on by default.
+
+
+ With this option enabled, the encoder will use some simple
+ heuristics to reduce the number of B-frames used in scenes that
+ might not benefit from them as much.
+ You can use to tweak how B-frame-happy
+ the encoder is.
+ The speed penalty of adaptive B-frames is currently rather modest,
+ but so is the potential quality gain.
+ It usually does not hurt, however.
+ Note that this only affects speed and frametype decision on the
+ first pass.
+ and have no
+ effect on subsequent passes.
+
+
+
+ b_pyramid:
+ You might as well enable this option if you are using >2 B-frames;
+ as the man page says, you get a little quality improvement with no
+ speed cost.
+ Note that these videos cannot be read by libavcodec-based decoders
+ older than about March 5, 2005.
+
+
+
+ weight_b:
+ In typical cases, there is not much gain with this option.
+ However, in crossfades or fade-to-black scenes, weighted
+ prediction gives rather large bitrate savings.
+ In MPEG-4 ASP, a fade-to-black is usually best coded as a series
+ of expensive I-frames; using weighted prediction in B-frames
+ makes it possible to turn at least some of these into much more
+ reasonably-sized B-frames.
+ Encoding time cost seems to be minimal, if there is any.
+ Also, contrary to what some people seem to guess, the decoder
+ CPU requirements are not much affected by weighted prediction,
+ all else being equal.
+
+
+ Unfortunately, the current adaptive B-frame decision algorithm
+ has a strong tendency to avoid B-frames during fades.
+ Until this changes, it may be a good idea to add
+ to your x264encopts, if you expect
+ fades to have a significant effect in your particular video
+ clip.
+
+
+
+ deblockalpha, deblockbeta:
+ This topic is going to be a bit controversial.
+
+
+ H.264 defines a simple deblocking procedure on I-blocks that uses
+ pre-set strengths and thresholds depending on the QP of the block
+ in question.
+ By default, high QP blocks are filtered heavily, and low QP blocks
+ are not deblocked at all.
+ The pre-set strengths defined by the standard are well-chosen and
+ the odds are very good that they are PSNR-optimal for whatever
+ video you are trying to encode.
+ The and
+ parameters allow you to specify offsets to the preset deblocking
+ thresholds.
+
+
+ Many people seem to think it is a good idea to lower the deblocking
+ filter strength by large amounts (say, -3).
+ This is however almost never a good idea, and in most cases,
+ people who are doing this do not understand very well how
+ deblocking works by default.
+
+
+ The first and most important thing to know about the in-loop
+ deblocking filter is that the default thresholds are almost always
+ PSNR-optimal.
+ In the rare cases that they are not optimal, the ideal offset is
+ plus or minus 1.
+ Adjusting deblocking parameters by a larger amount is almost
+ guaranteed to hurt PSNR.
+ Strengthening the filter will smear more details; weakening the
+ filter will increase the appearance of blockiness.
+
+
+ It is definitely a bad idea to lower the deblocking thresholds if
+ your source is mainly low in spacial complexity (i.e., not a lot
+ of detail or noise).
+ The in-loop filter does a rather excellent job of concealing
+ the artifacts that occur.
+ If the source is high in spacial complexity, however, artifacts
+ are less noticeable.
+ This is because the ringing tends to look like detail or noise.
+ Human visual perception easily notices when detail is removed,
+ but it does not so easily notice when the noise is wrongly
+ represented.
+ When it comes to subjective quality, noise and detail are somewhat
+ interchangeable.
+ By lowering the deblocking filter strength, you are most likely
+ increasing error by adding ringing artifacts, but the eye does
+ not notice because it confuses the artifacts with detail.
+
+
+
+ This still does not justify
+ lowering the deblocking filter strength, however.
+ You can generally get better quality noise from postprocessing.
+ If your H.264 encodes look too blurry or smeared, try playing with
+ when you play your encoded movie.
+ should conceal most mild
+ artifacting.
+ It will almost certainly look better than the results you
+ would have gotten just by fiddling with the deblocking filter.
+
+
+
+
+
How to deal with telecine and interlacing within NTSC DVDs