Mercurial > mplayer.hg
changeset 15370:bd6adbd632e4
Fixes suggested by Diego
author | gpoirier |
---|---|
date | Sun, 08 May 2005 21:48:02 +0000 |
parents | 37861a573823 |
children | 0ac7f66d02ef |
files | DOCS/xml/en/codecs.xml DOCS/xml/en/mencoder.xml |
diffstat | 2 files changed, 8 insertions(+), 8 deletions(-) [+] |
line wrap: on
line diff
--- a/DOCS/xml/en/codecs.xml Sun May 08 20:56:59 2005 +0000 +++ b/DOCS/xml/en/codecs.xml Sun May 08 21:48:02 2005 +0000 @@ -589,11 +589,11 @@ 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 + 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 + By comparison, decoding a 1500kbps MPEG-4 ASP stream requires around 10% CPU. This means that decoding high-definition streams is almost out of the question for most users. @@ -603,7 +603,7 @@ <para> At least with <systemitem class="library">x264</systemitem>, encoding requirements are not much worse than what you are used to - with MPEG4-ASP. + with MPEG-4 ASP. For instance, on a 1733 MHz Athlon a typical DVD encode would run at 5-15fps. </para>
--- a/DOCS/xml/en/mencoder.xml Sun May 08 20:56:59 2005 +0000 +++ b/DOCS/xml/en/mencoder.xml Sun May 08 21:48:02 2005 +0000 @@ -1814,7 +1814,7 @@ <title>Encoding with the <systemitem class="library">x264</systemitem> codec</title> <para> <systemitem class="library">x264</systemitem> is a free library for - encoding H264/AVC video streams. + encoding H.264/AVC video streams. Before starting to encode, you need to <link linkend="codec-x264-encode"> set up <application>MEncoder</application> to support it</link>. </para> @@ -1862,7 +1862,7 @@ 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 + with one 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 @@ -1945,7 +1945,7 @@ <option>subq</option> and <option>frameref</option> 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 + 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 <option>frameref</option> can occasionally affect frametype decision. @@ -1992,7 +1992,7 @@ <listitem><para> <emphasis role="bold">b_adapt</emphasis>: - Note: this is on by default. + Note: This is on by default. </para> <para> With this option enabled, the encoder will use some simple @@ -2012,7 +2012,7 @@ <listitem><para> <emphasis role="bold">b_pyramid</emphasis>: 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 + as the man page says, you get a little quality improvement at no speed cost. Note that these videos cannot be read by libavcodec-based decoders older than about March 5, 2005.