bandaid build fix

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@15352 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
diego 2005-05-05 13:26:59 +00:00
parent cafaabbf54
commit 64e88c0501
1 changed files with 143 additions and 0 deletions

View File

@ -547,6 +547,149 @@ Apple,
<step><para>ÓËÏÍÐÉÌÉÒÕÊÔÅ <application>MPlayer</application></para></step>
</procedure>
</sect3>
<sect3 id="codec-x264">
<title>x264</title>
<sect4 id="codec-x264-whatis">
<title>What is x264?</title>
<para>
<systemitem class="library">x264</systemitem> 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
<systemitem class="library">x264</systemitem>.
</para>
<itemizedlist>
<title>Encoder features</title>
<listitem><para>CAVLC/CABAC</para></listitem>
<listitem><para>Multi-references</para></listitem>
<listitem><para>Intra: all macroblock types (16x16 and 4x4 with
all predictions)</para></listitem>
<listitem><para>Inter P: all partitions (from 16x16 down to
4x4)</para></listitem>
<listitem><para>Inter B: partitions from 16x16 down to 8x8
(including SKIP/DIRECT)</para></listitem>
<listitem><para>Ratecontrol: constant quantizer, constant bitrate,
or multipass ABR</para></listitem>
<listitem><para>Scene cut detection</para></listitem>
<listitem><para>Adaptive B-frame placement</para></listitem>
<listitem><para>B-frames as references / arbitrary frame
order</para></listitem>
</itemizedlist>
<itemizedlist>
<title>Encoder limitations</title>
<listitem><para>No real RD</para></listitem>
</itemizedlist>
</sect4>
<sect4 id="codec-h264-whatis">
<title>What is H.264?</title>
<para>
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".
</para>
<para>
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.
</para>
<para>
At least with <systemitem class="library">x264</systemitem>,
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.
</para>
<para>
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
<ulink url="http://www.cdt.luth.se/~peppar/kurs/smd151/spie04-h264OverviewPaper.pdf">The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions</ulink>.
</para>
</sect4>
<sect4 id="codec-x264-playback">
<title>How can I play H.264 videos with <application>MPlayer</application>?</title>
<para>
<application>MPlayer</application> uses
<systemitem class="library">libavcodec</systemitem>'s H.264
decoder.
<systemitem class="library">libavcodec</systemitem> 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.
</para>
<para>
If you want a quick and easy way to know whether there have been
recent changes to <systemitem class="library">libavcodec</systemitem>'s
H.264 decoding, you might keep an eye on
<ulink url="http://mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/h264.c?cvsroot=FFMpeg">FFmpeg CVS repository's web interface</ulink>.
</para>
</sect4>
<sect4 id="codec-x264-encode">
<title>How can I encode videos using <application>MEncoder</application> and <systemitem class="library">x264</systemitem>?</title>
<para>
If you have the subversion client installed, the latest x264
sources can be gotten with this command:
<screen>
svn co svn://svn.videolan.org/x264/trunk x264
</screen>
<application>MPlayer</application> sources are updated whenever
an <systemitem class="library">x264</systemitem> API change
occurs, so it is always suggested to use CVS
<application>MPlayer</application> as well.
Perhaps this situation will change when and if an
<systemitem class="library">x264</systemitem> "release" occurs.
Meanwhile, <systemitem class="library">x264</systemitem> should
be considered very unstable, in the sense that its programming
interface is subject to change.
</para>
<para>
<systemitem class="library">x264</systemitem> is built and
installed in the standard way:
<screen>
./configure &amp;&amp; make &amp;&amp; sudo make install
</screen>
This installs libx264.a in /usr/local/lib and x264.h is placed in
/usr/local/include.
With the <systemitem class="library">x264</systemitem> library
and header placed in the standard locations, building
<application>MPlayer</application> with
<systemitem class="library">x264</systemitem> support is easy.
Just run the standard:
<screen>./configure &amp;&amp; make &amp;&amp; sudo make install</screen>
The configure script will autodetect that you have satisfied the
requirements for <systemitem class="library">x264</systemitem>.
</para>
</sect4>
</sect3>
</sect2>