March 2005 - MPlayer-DOCS - lists.mplayerhq.hu

Some points for cd-dvd.xml
by Jiri Heryan 01 Jul '05

01 Jul '05

About a line 31 in cd-dvd.xml is sugested to use "hdparm" or "cdspeed" for slow down IDE-CDROMs and few lines after is something like there is no solution for SCSI drives. I've no experience with cdspeed but hdparm failing with IDE-CD if you use an IDE-SCSI emulation for cd writer. Best solution (after hard searching) is set a speed=<speed> option to mount command. This work better for me than hdparm even in native ATAPI with my writer, because this drive resets its speed setting with every cd exchange so it need run hdparm many times (boring and slow). Maybe it is a solution for SCSI drives too. I can't prove it myself, have no native SCSI. Next we should point reasonable speed settings because all drives do not support many speeds. For example my cd writer supports about 15 various speeds but my previous toshiba cd-rom could be set to 14x and 40x only, so if I set 24x it turn out as 40x (noisy) but after I set it <=14x , it slowed down. In my experience is 8x speed reasonable minimum and 24x reasonable maximum with noise under fans level. Any ideas? Jiri

5 10

[PATCH] DOCS/tech/tearing.txt
by Oded Shimon 01 Jul '05

01 Jul '05

Simple document explaining all about what/why/how tearing is... I re-read again now, it seems to me all correct and good. Anyone spot anything incorrect or misleading in it? - ods15

5 7

[PATCH] small wording (and syntax) fix in video.xml
by Dominik 'Rathann' Mierzejewski 17 Jun '05

17 Jun '05

Here's an attempt to re-word an unclear sentence which I stumbled upon while reviewing Polish translation. Attached Also there's a paragraph around line 2090 of video.xml which reads: <varlistentry> <term><option>-vf expand=-1:-1:-1:-1:1</option></term> <listitem><para> Although the DXR3 driver can put some OSD onto the MPEG1/2/4 video, it has much lower quality than <application>MPlayer</application>'s traditional OSD, and has several refresh problems as well. The command line above will firstly convert the input video to MPEG4 (this is mandatory, sorry), then apply an expand filter which won't expand anything (-1: default), but apply the normal OSD onto the picture (that's what the "1" at the end does). </para></listitem> </varlistentry> Does expand really convert input to MPEG4? I don't think so. R. -- MPlayer RPMs maintainer: http://greysector.rangers.eu.org/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"

3 11

CVS: main/DOCS/man/en mplayer.1,1.914,1.915
by syncmail＠mplayerhq.hu 18 Apr '05

18 Apr '05

CVS change done by Jonas Jermann CVS Update of /cvsroot/mplayer/main/DOCS/man/en In directory mail:/var2/tmp/cvs-serv8653 Modified Files: mplayer.1 Log Message: Small fixes. Index: mplayer.1 =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/man/en/mplayer.1,v retrieving revision 1.914 retrieving revision 1.915 diff -u -r1.914 -r1.915 --- mplayer.1 14 Mar 2005 23:26:10 -0000 1.914 +++ mplayer.1 16 Mar 2005 12:49:29 -0000 1.915 @@ -575,7 +575,7 @@ Prints all commands that can be bound to keys. .IPs js-dev Specifies the joystick device to use (default: /dev/\:input/\:js0). -.IPs file\ +.IPs file=<filename> Read commands from the given file. Mostly useful with a FIFO. .br @@ -8117,6 +8117,7 @@ .TP .B Play a 6-channel AAC file with only two speakers: mplayer \-rawaudio on:format=0xff \-af pan=6:.32:.39:.06:.17:-.17:.33:.32:.06:.39:-.17:.17:.33 adts_he-aac160_51.aac +.br You might want to play a bit with the pan values (e.g multiply with a value) to increase volume or avoid clipping. .

5 11

faq.xml
by Torinthiel 16 Apr '05

16 Apr '05

faq.xml, lines 775-784: Check <command>ldd /usr/local/bin/mplayer</command> output. If it contains <screen>libc.so.6 => /lib/libc.so.6 (0x4???????)</screen> where "?" is any number then it's OK, the error is not here. If it is: <screen>libc.so.6 => /lib/libc.so.6 (0x00??????)</screen> then there is a problem with your kernel/libc. Maybe you are using some security patches (for example Solar Designer's OpenWall patch) which forces loading libraries to very low addresses. Because <filename>l3codeca.acm</filename> is a non-relocatable DLL, it must be loaded to <literal>0x40000000</literal>, we can't change this. You should use a non-patched kernel, or use <application>MPlayer</application>'s <option>-afm 1</option> option to disable using <filename>l3codeca.acm</filename>. Now there is something strange here. Assume l3codeca.acm has to be loaded at 0x40000000 (as written, I haven't looked at the code). Then how low-loading libc (low means 0x00??????) breaks the code? IMHO the high-loading (0x4???????) can (but not necessary does) overlap. Again, I haven't looked at the code, and it might be something really simple, but I'm a bit confused. Torinthiel -- Waclaw "Torinthiel" Schiller GG#: 542916, 3073512 torinthiel(at)megapolis(dot)pl gpg: 0906A2CE fpr: EE3E DFB4 C4D6 E22E 8999 D714 7CEB CDDC 0906 A2CE "No classmates may be used during this examination"

2 1

CVS: main/DOCS/xml/en mencoder.xml,1.39,1.40
by syncmail＠mplayerhq.hu 11 Apr '05

11 Apr '05

CVS change done by Guillaume Poirier CVS Update of /cvsroot/mplayer/main/DOCS/xml/en In directory mail:/var2/tmp/cvs-serv23999 Modified Files: mencoder.xml Log Message: Improved encoding guide: - explains how to do a smart resize - calculate a bitrate to target a certain size - rip audio and transcode in Ogg/Vorbis - a lot of libavcodec's options to come: muxing in matroska files... Index: mencoder.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/mencoder.xml,v retrieving revision 1.39 retrieving revision 1.40 diff -u -r1.39 -r1.40 --- mencoder.xml 19 Mar 2005 16:55:25 -0000 1.39 +++ mencoder.xml 25 Mar 2005 21:17:21 -0000 1.40 @@ -521,15 +521,15 @@ <title>Making a high quality MPEG-4 ("DivX") rip of a DVD movie</title> <para> - One frequently asked question is "How do I make the highest quality DVD - rip possible? I don't care about file size, I just want the best - quality." + One frequently asked question is "How do I make highest quality rip for + a given size?". Another question is "How do I make the highest quality DVD + rip possible? I don't care about file size, I just want the best quality." </para> <para> - This 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 + The latter question is perhaps at least somewhat wrongly posed. After all, if + you don't care about file size, why not simply copy the entire MPEG-2 video + stream from the the DVD? Sure, your AVI will end up being 5GB, give or take, but if you want the best quality and don't care about size, this is certainly your best option. </para> @@ -551,11 +551,12 @@ </para> <para> - The main assumption of this guide is that you have no specific file size - constraints and have no problem giving up bits in exchange for quality. - While much of the information presented here is useful in any case, some - of it may work against you if you have a file size goal, such as fitting a - video on a CD. + 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, because most of those tools are designed to take clever decisions + for you. </para> <sect2 id="menc-feat-dvd-mpeg4-2pass"> @@ -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 which will be exposed later on that guide. + In general, you should avoid CBR altogether if you care about quality. </para> <para> @@ -642,13 +645,26 @@ </para> <para> - 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. + If size doesn't 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's a good idea to experiment with scenes at different bitrates to get a feel. </para> +<para> + 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 <link linkend="menc-feat-dvd-mpeg4-audio">rip + those</link> first. + 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 a two-hour movie into a 702Mbytes CD, with 60Mbytes + of audio track, the video bitrate will have to be + (702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000 = 740kbps. +</para> + </sect2> <sect2 id="menc-feat-dvd-mpeg4-crop"> @@ -677,6 +693,9 @@ scaling video.) If you're not comfortable throwing a few extra pixels away, you might prefer instead to scale the video instead. We'll look at this in our example below. + 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. </para> <para> @@ -691,10 +710,62 @@ could calculate the new aspect ratio manually, but <application>MEncoder</application> offers an option for <systemitem class="library">libavcodec</systemitem> called <option>autoaspect</option> - that will do this for you. Absolutely do not scale this video in order to + that will do this for you. Absolutely do not scale this video up in order to square the pixels unless you like to waste your hard disk space. Scaling should be done on playback, and the player will use the aspect stored in the AVI to determine the correct resolution. + Unfortunately, not all players enforce this auto-scaling information, + therefore you may still want to rescale. +</para> + +<para> + First, you should compute the encoded aspect ratio: + ARc = (Wc x (ARa / PRdvd )) / Hc +<itemizedlist> +<title>where:</title> +<listitem><para> + Wc and Hc are the width and height of the cropped video, +</para></listitem> +<listitem><para> + PRdvd is the pixel ratio of the DVD wich is equal to 1.25=(720/576) for PAL, +</para></listitem> +<listitem><para> + DVDs and 1.5=(720/480) for NTSC DVDs, +</para></listitem> +</itemizedlist> +</para> + +<para> + Then, you can compute the X and Y resolution, according to a certain + Compression Quality (CQ) factor: + ResY = INT( SQRT(1000 * Bitrate / 25 / ARc / CQ) / 16 ) * 16 + ResX = INT( ResY * ARc / 16) * 16 +</para> + +<para> + Okay, but what is the CQ? + The CQ represents the number of bits per pixel and per frame of the encode. + Roughly speaking, the greater the CQ, the less the likelihood to see + encoding artifacts. + However, if you have a target size for your movie (1 or 2 CDs for instance), + there's a limited total number of bits that you can spend; therefore it's + necessary to find a good tradeoff between compressibility and quality. + The CQ depends both on the bitrate and the movie resolution. + In order to raise the CQ, typically you'd downscale the movie given that the + bitrate is computed in function of the target size and the length of the + movie, which are constant. + A CQ below 0.18 usually ends up in a very blocky picture, because 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; if there aren't enough bits, the edge of those blocks are + visible). + It's therefore wise to take a CQ ranging from 0.20 to 0.22 for a 1 CD rip, + and 0.26-0.28 for 2 CDs. + Please thake note that 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 The Matrix, which contains many high-motion scenes. + On the other hand, it's worthless to raise CQ as higher than 0.30 as you'd + be wasting bits without any noticeable quality gain. </para> </sect2> @@ -703,14 +774,54 @@ <title>Audio</title> <para> - Audio is a much simpler problem to solve: just leave it as is. Even AC3 - 5.1 streams are at most 448Kbit/s, and they're worth every bit. You - might be tempted to transcode the audio to high quality Ogg Vorbis, but + Audio is a much simpler problem to solve: if you care about quality, just + leave it as is. + Even AC3 5.1 streams are at most 448Kbit/s, and they're worth every bit. + You might be tempted to transcode the audio to high quality Ogg Vorbis, but just because you don't have an A/V receiver for AC3 pass-through today doesn't mean you won't have one tomorrow. Future-proof your DVD rips by preserving the AC3 stream. + You can keep the AC3 stream either by copying it directly into the video + stream <link linkend="menc-feat-mpeg4">during the encoding</link>. + You can also extract the AC3 stream in order to mux it into containers such + as NUT, Matroska or OGM. + <screen>mplayer source_file.vob -aid 129 -dumpaudio -dumpfile sound.ac3</screen> + will dump into the file sound.ac3 the audio track number 129 from the file + source_file.vob (NB: DVD VOB files usually use a different audio numbering, + which means that the VOB audio track 128 is the 2nd audio track of the file). </para> +<para> + But sometimes you truly have no choice but to further compress the + sound so that more bits can be spent on the video. + Most people choose to compress audio with either MP3 or Ogg Vorbis audio + codecs. + While the latter is a very space-efficient codec, MP3 is better supported + by hardware players, although this trend is changing. +</para> + +<para> + First of all, you will have to convert the DVD sound into a WAV file that the + audio codec can use as input. + For example: + <screen>mplayer source_file.vob -ao pcm:file=destination_sound.wav -vc dummy -aid 1 -vo null</screen> + will 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 commonly recorded at low volumes. + You can use the tool <application>normalize</application> for instance, + which is available in most distribution. + You will compress in either Ogg Vorbis or MP3. + For example: + <screen>oggenc -q1 destination_sound.wav</screen> + will encode destination_sound.wav with the encoding quality 1, which is + roughly equivalent to 80Kb/s, and is the minimum quality at which you + should encode if you care about quality. + Please note that MEncoder currently can't currently mux Ogg Vorbis files + into a video stream because it can only create AVI and MPEG files. + Don't worry, this document will show you how you can do that with third + party programs. +</para> </sect2> @@ -801,6 +912,153 @@ </sect2> +<sect2 id="menc-feat-dvd-mpeg4-encoding-options"> +<title>Encoding options</title> + +<para> + Ideally, you'd probably want to be able to just tell the encoder to switch + into "high quality" mode and move 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. + The good news is 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. +</para> + + +<itemizedlist> +<title>Options to adjust:</title> +<listitem><para> + <emphasis role="bold">vmax_b_frames</emphasis>: 1 or 2 is good, depending on + the movie. + Note that libavcodec 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. +</para></listitem> + +<listitem><para> + <emphasis role="bold">vb_strategy=1</emphasis>: helps in high-motion scenes. + Requires vmax_b_frames >= 2. + On some videos, vmax_b_frames may hurt quality, but vmax_b_frames=2 along + with vb_strategy=1 helps. +</para></listitem> + +<listitem><para> + <emphasis role="bold">dia</emphasis>: motion search range. Bigger is better + and slower. + Negative values are a completely different scale. + Good values are -1 for a fast encode, or 2-4 for slower. +</para></listitem> + +<listitem><para> + <emphasis role="bold">predia</emphasis>: motion search pre-pass. + Not as important as dia. Good values are 1 (default) to 4. Requires preme=2 + to really be useful. +</para></listitem> + +<listitem><para> + <emphasis role="bold">cmp, subcmp, precmp</emphasis>: Comparison function for + motion estimation. + Experiment with values of 0 (default), 2 (hadamard), 3 (dct), and 6 (rate + distortion). + 0 is fastest, and sufficient for precmp. + For cmp and subcmp, 2 is good for anime, and 3 is good for live action. + 6 may or may not be slightly better, but is slow. +</para></listitem> + +<listitem><para> + <emphasis role="bold">last_pred</emphasis>: Number of motion predictors to + take from the previous frame. + 1-3 or so help at little speed cost. + Higher values are slow for no extra gain. +</para></listitem> + +<listitem><para> + <emphasis role="bold">cbp, mv0</emphasis>: Controls the selection of macroblocks. + Small speed cost for small quality gain. +</para></listitem> + +<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); vqmin=1 should also help. +</para></listitem> + +<listitem><para> + <emphasis role="bold">qns</emphasis>: very slow, especially when combined + with qprd. + This option will make the encoder reduce as much as possible noise due to + compression artifacts instead making the encoded video strictly match the + source. + Don't use this unless you've already tweaked everything else as far as it + will go and the results still aren't good enough. +</para></listitem> + +<listitem><para> + <emphasis role="bold">vqcomp</emphasis>: Tweak ratecontrol. + What values are good depends on the movie. + You can safely leave this alone if you want. + Reducing vqcomp puts more bits on low-complexity scenes, increasing it puts + them on high-complexity scenes (default: 0.5, range: 0-1. recommended range: + 0.5-0.7). +</para></listitem> + +<listitem><para> + <emphasis role="bold">vlelim, vcelim</emphasis>: Sets the single coefficient + elimination threshold for luminance and chroma planes. + These are encoded separately in all MPEG-like algorithms. + 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; + when encoding animation, you should probably leave them unchanged. +</para></listitem> + +<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 information will be + stored in the encoded file. + 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). +</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 + prints a sumary of PSNR (Peak Signal to Noise Ratio) at the end. +</para></listitem> + +</itemizedlist> + +<itemizedlist> +<title>Options not recommended to play with:</title> +<listitem><para> + <emphasis role="bold">vme</emphasis>: The default is best. +</para></listitem> + +<listitem><para> + <emphasis role="bold">lumi_mask, dark_mask</emphasis>: Psychovisual adaptive + quantization. + You don't want to play with those options if you care about quality. + Reasonable values may be effective in your case, but be warned this is a very + subjective. +</para></listitem> + +<listitem><para> + <emphasis role="bold">scplx_mask</emphasis>: Tries to prevent blocky + artifacts, but postprocessing is better. +</para></listitem> +</itemizedlist> + +</sect2> <sect2 id="menc-feat-dvd-mpeg4-example"> <title>Example</title> @@ -1372,7 +1630,7 @@ <blockquote><para>It's OK, but IMO it tries to deinterlace rather than doing inverse telecine too often (much like settop DVD players & progressive TVs) which gives ugly flickering and - other artefacts. If you're going to use it, you at least need to + other artifacts. If you're going to use it, you at least need to spend some time tuning the options and watching the output first to make sure it's not messing up.</para></blockquote> </para></listitem>

10 28

CVS: main/DOCS/xml/en bugreports.xml, 1.10, 1.11 faq.xml, 1.68, 1.69 mencoder.xml, 1.40, 1.41 ports.xml, 1.60, 1.61 video.xml, 1.78, 1.79
by syncmail＠mplayerhq.hu 01 Apr '05

01 Apr '05

CVS change done by Diego Biurrun CVS Update of /cvsroot/mplayer/main/DOCS/xml/en In directory mail:/var2/tmp/cvs-serv24230 Modified Files: bugreports.xml faq.xml mencoder.xml ports.xml video.xml Log Message: correct spelling for mailing list names Index: bugreports.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/bugreports.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- bugreports.xml 26 Jun 2004 14:30:33 -0000 1.10 +++ bugreports.xml 31 Mar 2005 22:28:24 -0000 1.11 @@ -18,7 +18,7 @@ bug yourself. Or maybe you already did that? Please read <ulink url="../../tech/patches.txt">this short document</ulink> to find out how to get your code included in <application>MPlayer</application>. The people on the -<ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng">mplayer-dev-eng</ulink> +<ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng">MPlayer-dev-eng</ulink> mailing list will assist you if you have questions. </para> </sect1> @@ -73,7 +73,7 @@ <sect1 id="bugreports_where"> <title>Where to report bugs</title> <para> -Subscribe to the mplayer-users mailing list: +Subscribe to the MPlayer-users mailing list: <ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-users"/> and send your bug report to <ulink url="mailto:mplayer-users@mplayerhq.hu"/> where you can discuss it. @@ -316,7 +316,7 @@ If you created a proper bug report following the steps above and you are confident it is a bug in <application>MPlayer</application>, not a compiler problem or broken file, you have already read the documentation and you could not find a solution, -your sound drivers are OK, then you might want to subscribe to the mplayer-advusers +your sound drivers are OK, then you might want to subscribe to the MPlayer-advusers list and send your bug report there to get a better and faster answer. </para> Index: faq.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/faq.xml,v retrieving revision 1.68 retrieving revision 1.69 diff -u -r1.68 -r1.69 --- faq.xml 31 Mar 2005 22:06:55 -0000 1.68 +++ faq.xml 31 Mar 2005 22:28:24 -0000 1.69 @@ -25,7 +25,7 @@ <answer><para> Read the <ulink url="../../tech/translations.txt">translation HOWTO</ulink>, it should explain everything. You can get further help on the -<ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-docs">mplayer-docs</ulink> +<ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-docs">MPlayer-docs</ulink> mailing list. </para></answer> </qandaentry> @@ -49,10 +49,10 @@ We always welcome coders and documenters. Read the <ulink url="../../tech/">technical documentation</ulink> to get a first grasp. Then you should subscribe to the -<ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng">mplayer-dev-eng</ulink> +<ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng">MPlayer-dev-eng</ulink> mailing list and start coding. If you want to help out with the documentation, join the -<ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-docs">mplayer-docs</ulink> +<ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-docs">MPlayer-docs</ulink> mailing list. </para></answer> </qandaentry> @@ -200,7 +200,7 @@ </para></question> <answer><para> Quoted from a <ulink url="http://www.mplayerhq.hu/pipermail/mplayer-users/2001-October/005351.html">mail</ulink> -A'rpi sent to the <ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink> +A'rpi sent to the <ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">MPlayer-users</ulink> list (the word 'ideg' is described below): <blockquote> <para> Index: mencoder.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/mencoder.xml,v retrieving revision 1.40 retrieving revision 1.41 diff -u -r1.40 -r1.41 --- mencoder.xml 25 Mar 2005 21:17:21 -0000 1.40 +++ mencoder.xml 31 Mar 2005 22:28:24 -0000 1.41 @@ -8,7 +8,7 @@ and examples, please see the man page. For a series of hands-on examples and detailed guides on using several encoding parameters, read the <ulink url="../../tech/encoding-tips.txt">encoding-tips</ulink> that were -collected from several mailing list threads on mplayer-users. Search the +collected from several mailing list threads on MPlayer-users. Search the <ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">archives</ulink> for a wealth of discussions about all aspects of and problems related to encoding with <application>MEncoder</application>. Index: ports.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/ports.xml,v retrieving revision 1.60 retrieving revision 1.61 diff -u -r1.60 -r1.61 --- ports.xml 1 Feb 2005 13:07:00 -0000 1.60 +++ ports.xml 31 Mar 2005 22:28:24 -0000 1.61 @@ -414,7 +414,7 @@ It does not have a GUI yet, but the command line version is almost completely functional. <ulink url="../../tech/patches.txt">Patches</ulink> are always welcome. You should check out the - <ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-cygwin/">mplayer-cygwin</ulink> + <ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-cygwin/">MPlayer-cygwin</ulink> mailing list for help and latest information.</para> <para>Best results are achieved with the native DirectX video output driver Index: video.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/video.xml,v retrieving revision 1.78 retrieving revision 1.79 diff -u -r1.78 -r1.79 --- video.xml 19 Mar 2005 16:55:25 -0000 1.78 +++ video.xml 31 Mar 2005 22:28:24 -0000 1.79 @@ -195,7 +195,7 @@ <para> It's currently unclear which Savage models lack YV12 support, and convert by driver (slow). If you suspect your card, get a newer driver, or ask politely -on the mplayer-users mailing list for an MMX/3DNow! enabled driver. +on the MPlayer-users mailing list for an MMX/3DNow! enabled driver. </para> </note> </sect4>

3 2

CVS: main/DOCS/xml/en mencoder.xml,1.41,1.42
by syncmail＠mplayerhq.hu 01 Apr '05

01 Apr '05

CVS change done by Guillaume Poirier CVS Update of /cvsroot/mplayer/main/DOCS/xml/en In directory mail:/var2/tmp/cvs-serv17272 Modified Files: mencoder.xml Log Message: Fixes better wording. Suggestions by The Wanderer and Josh Varner. Index: mencoder.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/mencoder.xml,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- mencoder.xml 31 Mar 2005 22:28:24 -0000 1.41 +++ mencoder.xml 31 Mar 2005 22:31:18 -0000 1.42 @@ -592,8 +592,8 @@ 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 order to avoid that, you should probably down-scale your video, according - to the method which will be exposed later on that guide. + In order to avoid that, you should probably down scale your video, according + to the method which will be gone over later on that guide. In general, you should avoid CBR altogether if you care about quality. </para> @@ -751,7 +751,7 @@ there's a limited total number of bits that you can spend; therefore it's necessary to find a good tradeoff between compressibility and quality. The CQ depends both on the bitrate and the movie resolution. - In order to raise the CQ, typically you'd downscale the movie given that the + In order to raise the CQ, typically you'd down scale the movie given that the bitrate is computed in function of the target size and the length of the movie, which are constant. A CQ below 0.18 usually ends up in a very blocky picture, because there @@ -810,7 +810,9 @@ You may want to normalize the sound before encoding, as DVD audio tracks are commonly recorded at low volumes. You can use the tool <application>normalize</application> for instance, - which is available in most distribution. + which is available in most distributions. + If you're using Windows, a tool such as <application>BeSweet</application> + can do the same job. You will compress in either Ogg Vorbis or MP3. For example: <screen>oggenc -q1 destination_sound.wav</screen> @@ -920,11 +922,13 @@ into "high quality" mode and move 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. + That's because compression depends on the visual properties of the video + in question. + For example, anime and live action have very different properties and + thus require different options to obtain optimum encoding. The good news is 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. + See below a for detailed description of common encoding options. </para> @@ -991,9 +995,8 @@ <listitem><para> <emphasis role="bold">qns</emphasis>: very slow, especially when combined with qprd. - This option will make the encoder reduce as much as possible noise due to - compression artifacts instead making the encoded video strictly match the - source. + This option will make the encoder minimize noise due to compression + artifacts instead making the encoded video strictly match the source. Don't use this unless you've already tweaked everything else as far as it will go and the results still aren't good enough. </para></listitem> @@ -1048,7 +1051,7 @@ <emphasis role="bold">lumi_mask, dark_mask</emphasis>: Psychovisual adaptive quantization. You don't want to play with those options if you care about quality. - Reasonable values may be effective in your case, but be warned this is a very + Reasonable values may be effective in your case, but be warned this is very subjective. </para></listitem>

4 5

CVS: main/DOCS/xml/en mencoder.xml,1.42,1.43
by syncmail＠mplayerhq.hu 01 Apr '05

01 Apr '05

CVS change done by Diego Biurrun CVS Update of /cvsroot/mplayer/main/DOCS/xml/en In directory mail:/var2/tmp/cvs-serv10972/en Modified Files: mencoder.xml Log Message: misc fixes Index: mencoder.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/mencoder.xml,v retrieving revision 1.42 retrieving revision 1.43 diff -u -r1.42 -r1.43 --- mencoder.xml 31 Mar 2005 22:31:18 -0000 1.42 +++ mencoder.xml 31 Mar 2005 23:55:45 -0000 1.43 @@ -521,7 +521,7 @@ <title>Making a high quality MPEG-4 ("DivX") rip of a DVD movie</title> <para> - One frequently asked question is "How do I make highest quality rip for + One frequently asked question is "How do I make the highest quality rip for a given size?". Another question is "How do I make the highest quality DVD rip possible? I don't care about file size, I just want the best quality." </para> @@ -552,8 +552,9 @@ <para> 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>. + many fine frontends that are listed in the + <ulink url="http://mplayerhq.hu/homepage/design7/projects.html#mencoder_frontends">MEncoder section</ulink> + of our related projects page. That way, you should be able to achieve high quality rips without too much thinking, because most of those tools are designed to take clever decisions for you. @@ -592,8 +593,8 @@ 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 order to avoid that, you should probably down scale your video, according - to the method which will be gone over later on that guide. + 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. </para> @@ -660,7 +661,7 @@ those</link> first. 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 a two-hour movie into a 702Mbytes CD, with 60Mbytes + For instance, to squeeze a two-hour movie onto a 702MB CD, with 60MB of audio track, the video bitrate will have to be (702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000 = 740kbps. </para> @@ -751,20 +752,20 @@ there's a limited total number of bits that you can spend; therefore it's necessary to find a good tradeoff between compressibility and quality. The CQ depends both on the bitrate and the movie resolution. - In order to raise the CQ, typically you'd down scale the movie given that the + In order to raise the CQ, typically you'd downscale the movie given that the bitrate is computed in function of the target size and the length of the movie, which are constant. A CQ below 0.18 usually ends up in a very blocky picture, because 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; if there aren't enough bits, the edge of those blocks are + image; if there aren't enough bits, the edges of those blocks are visible). It's therefore wise to take a CQ ranging from 0.20 to 0.22 for a 1 CD rip, and 0.26-0.28 for 2 CDs. Please thake note that 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 The Matrix, which contains many high-motion scenes. - On the other hand, it's worthless to raise CQ as higher than 0.30 as you'd + On the other hand, it's worthless to raise CQ higher than 0.30 as you'd be wasting bits without any noticeable quality gain. </para> @@ -777,7 +778,7 @@ Audio is a much simpler problem to solve: if you care about quality, just leave it as is. Even AC3 5.1 streams are at most 448Kbit/s, and they're worth every bit. - You might be tempted to transcode the audio to high quality Ogg Vorbis, but + You might be tempted to transcode the audio to high quality Vorbis, but just because you don't have an A/V receiver for AC3 pass-through today doesn't mean you won't have one tomorrow. Future-proof your DVD rips by preserving the AC3 stream. @@ -788,13 +789,13 @@ <screen>mplayer source_file.vob -aid 129 -dumpaudio -dumpfile sound.ac3</screen> will dump into the file sound.ac3 the audio track number 129 from the file source_file.vob (NB: DVD VOB files usually use a different audio numbering, - which means that the VOB audio track 128 is the 2nd audio track of the file). + which means that the VOB audio track 129 is the 2nd audio track of the file). </para> <para> But sometimes you truly have no choice but to further compress the sound so that more bits can be spent on the video. - Most people choose to compress audio with either MP3 or Ogg Vorbis audio + Most people choose to compress audio with either MP3 or Vorbis audio codecs. While the latter is a very space-efficient codec, MP3 is better supported by hardware players, although this trend is changing. @@ -813,13 +814,13 @@ which is available in most distributions. If you're using Windows, a tool such as <application>BeSweet</application> can do the same job. - You will compress in either Ogg Vorbis or MP3. + You will compress in either Vorbis or MP3. For example: <screen>oggenc -q1 destination_sound.wav</screen> will encode destination_sound.wav with the encoding quality 1, which is roughly equivalent to 80Kb/s, and is the minimum quality at which you should encode if you care about quality. - Please note that MEncoder currently can't currently mux Ogg Vorbis files + Please note that MEncoder currently cannot mux Ogg Vorbis files into a video stream because it can only create AVI and MPEG files. Don't worry, this document will show you how you can do that with third party programs. @@ -921,14 +922,14 @@ Ideally, you'd probably want to be able to just tell the encoder to switch into "high quality" mode and move on. That would probably be nice, but unfortunately hard to implement as different - encoding options yield different qualities depending on the source material. + encoding options yield different quality results depending on the source material. That's because compression depends on the visual properties of the video in question. For example, anime and live action have very different properties and thus require different options to obtain optimum encoding. The good news is that some options should never be left out, like <option>mbd=2</option>, <option>trell</option>, and <option>v4mv</option>. - See below a for detailed description of common encoding options. + See below for a detailed description of common encoding options. </para> @@ -1018,25 +1019,25 @@ 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; + seem to be good for live movies, but seem not to help with anime; when encoding animation, you should probably leave them unchanged. </para></listitem> <listitem><para> <emphasis role="bold">qpel</emphasis>: Quarter pixel motion estimation. - MPEG-4 uses a half pixel precision for its motion search by default, + MPEG-4 uses half pixel precision for its motion search by default, therefore this option comes with an overhead as more information will be stored in the encoded file. 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 + qpel always incurs a significant cost in CPU decode time (+20% in practice). </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 - prints a sumary of PSNR (Peak Signal to Noise Ratio) at the end. + prints a summary of PSNR (Peak Signal to Noise Ratio) at the end. </para></listitem> </itemizedlist>

1 0

New MAINTAINERS file
by Dominik 'Rathann' Mierzejewski 01 Apr '05

01 Apr '05

Hi. As mentioned at mplayer-dev-eng, I think a MAINTAINERS file will be useful, even if only to see which parts need someone to take care of them. First draft based on Linux kernel's MAINTAINERS and what little knowledge I have, is attached. Comments? R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"

1 0