From 685bbb5734014ac6efece02d7df757fb4a942cbb Mon Sep 17 00:00:00 2001 From: Uoti Urpala Date: Tue, 15 Feb 2011 12:08:16 +0200 Subject: DOCS/xml/en: remove various outdated documentation The XML documentation was badly outdated, with various obsolete, useless and and sometimes actively harmful advice. Delete a lot of the obsolete stuff, without spending much effort to replace it for now. In the FAQ section I removed some questions completely; in other cases I only removed the answer if I thought the entry might be worth keeping but the answer would need to be updated. --- DOCS/xml/en/bugreports.xml | 260 +- DOCS/xml/en/documentation.xml | 106 +- DOCS/xml/en/encoding-guide.xml | 5545 +--------------------------------------- DOCS/xml/en/faq.xml | 647 +---- DOCS/xml/en/install.xml | 413 +-- DOCS/xml/en/mencoder.xml | 771 +----- DOCS/xml/en/ports.xml | 833 +----- DOCS/xml/en/usage.xml | 119 +- DOCS/xml/en/video.xml | 2301 +---------------- 9 files changed, 43 insertions(+), 10952 deletions(-) (limited to 'DOCS') diff --git a/DOCS/xml/en/bugreports.xml b/DOCS/xml/en/bugreports.xml index 786c2516ef..dbcffcb88a 100644 --- a/DOCS/xml/en/bugreports.xml +++ b/DOCS/xml/en/bugreports.xml @@ -41,13 +41,7 @@ send that one with another mail. How to fix bugs -If you feel have the necessary skills you are invited to have a go at fixing the -bug yourself. Or maybe you already did that? Please read -this short document to find out how -to get your code included in MPlayer. The people on -the -MPlayer-dev-eng -mailing list will assist you if you have questions. +OUTDATED CONTENT REMOVED @@ -59,84 +53,7 @@ mailing list will assist you if you have questions. How to do regression testing using Subversion -A problem that can happen sometimes is 'it used to work before, now it -doesn't anymore...'. -Here is a step by step procedure to try to pinpoint when the problem -occurred. This is not for casual users. - - - -First, you'd need to fetch MPlayer's source tree from Subversion. -Instructions can be found in the -Subversion section of the download page. - - - -You will have now in the mplayer/ directory an image of the Subversion tree, on -the client side. -Now update this image to the date you want: - -cd mplayer/ -svn update -r {"2004-08-23"} - -The date format is YYYY-MM-DD HH:MM:SS. -Using this date format ensure that you will be able to extract patches -according to the date at which they were committed, as in the -MPlayer-cvslog archive. - - - -Now proceed as for a normal update: - -./configure -make - - - - -If any non-programmer reads this, the fastest method to get at the point -where the problem occurred is to use a binary search — that is, -search the date of the breakage by repeatedly dividing the search -interval in half. -For example, if the problem occurred in 2003, start at mid-year, then ask -"Is the problem already here?". -If yes, go back to the first of April; if not, go to the first of October, -and so on. - - - -If you have lot of free hard disk space (a full compile currently takes -100 MB, and around 300-350 MB if debugging symbols are enabled), copy the -oldest known working version before updating it; this will save time if -you need to go back. -(It is usually necessary to run 'make distclean' before recompiling an -earlier version, so if you do not make a backup copy of your original -source tree, you will have to recompile everything in it when you come -back to the present.) -Alternatively you may use ccache -to speed up compilation. - - - -When you have found the day where the problem happened, continue the search -using the mplayer-cvslog archive (sorted by date) and a more precise svn -update including hour, minute and second: - -svn update -r {"2004-08-23 15:17:25"} - -This will allow you to easily find the exact patch that did it. - - - -If you find the patch that is the cause of the problem, you have almost won; -report about it to the -MPlayer Bugzilla or -subscribe to -MPlayer-users -and post it there. -There is a chance that the author will jump in to suggest a fix. -You may also look hard at the patch until it is coerced to reveal where -the bug is :-). +OUTDATED CONTENT REMOVED @@ -148,49 +65,7 @@ the bug is :-). How to report bugs -First of all please try the latest Subversion version of -MPlayer -as your bug might already be fixed there. Development moves extremely fast, -most problems in official releases are reported within days or even hours, -so please use only Subversion to report bugs. -This includes binary packages of MPlayer. -Subversion instructions can be found at the bottom of -this page or in -the README. If this did not help please refer to the rest of the documentation. -If your problem is not known or not solvable by our instructions, -then please report the bug. - - - -Please do not send bug reports privately to individual developers. This is -community work and thus there might be several people interested in it. -Sometimes other users already experienced your troubles and know how to -circumvent a problem even if it is a bug in MPlayer -code. - - - -Please describe your problem in as much detail as possible. Do a little -detective work to narrow down the circumstances under which the problem occurs. -Does the bug only show up in certain situations? Is it specific to certain -files or file types? Does it occur with only one codec or is it codec -independent? Can you reproduce it with all output drivers? The more information -you provide the better are our chances at fixing your problem. Please do not -forget to also include the valuable information requested below, we will be -unable to properly diagnose your problem otherwise. - - - -An excellent and well written guide to asking questions in public forums is -How To Ask Questions The Smart Way -by Eric S. Raymond. -There is another called -How to Report Bugs Effectively -by Simon Tatham. -If you follow these guidelines you should be able to get help. But please -understand that we all follow the mailing lists voluntarily in our free time. We -are very busy and cannot guarantee that you will get a solution for your problem -or even an answer. +OUTDATED CONTENT REMOVED @@ -202,15 +77,7 @@ or even an answer. Where to report bugs -Subscribe to the MPlayer-users mailing list: - -and send your bug report to - where you can discuss it. - - - -If you prefer, you can use our brand-new -Bugzilla instead. +OUTDATED CONTENT REMOVED @@ -235,12 +102,7 @@ to subscribe to actually receive your answer. What to report -You may need to include log, configuration or sample files in your bug report. -If some of them are quite big then it is better to upload them to our -FTP server in a -compressed format (gzip and bzip2 preferred) and include only the path and file -name in your bug report. Our mailing lists have a message size limit of 80k, if -you have something bigger you have to compress or upload it. +OUTDATED CONTENT REMOVED @@ -249,57 +111,7 @@ you have something bigger you have to compress or upload it. System Information - - - Your Linux distribution or operating system and version e.g.: - - Red Hat 7.1 - Slackware 7.0 + devel packs from 7.1 ... - - - - kernel version: - uname -a - - - libc version: - ls -l /lib/libc[.-]* - - - gcc and ld versions: - -gcc -v -ld -v - - - binutils version: - as --version - - - If you have problems with fullscreen mode: - - Window manager type and version - - - - If you have problems with XVIDIX: - - - X colour depth: - xdpyinfo | grep "depth of root" - - - - - If only the GUI is buggy: - - GTK version - GLIB version - GUI situation in which the bug occurs - - - +OUTDATED CONTENT REMOVED @@ -309,39 +121,7 @@ ld -v - - - -I know what I am doing... - - -If you created a proper bug report following the steps above and you are -confident it is a bug in MPlayer, 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 list and send your bug report there to get -a better and faster answer. - - - -Please be advised that if you post newbie questions or questions answered in the -manual there, you will be ignored or flamed instead of getting an appropriate -answer. So do not flame us and subscribe to -advusers only if you really know -what you are doing and feel like being an advanced -MPlayer user or developer. If you meet these -criteria it should not be difficult to find out how to subscribe... - - - diff --git a/DOCS/xml/en/documentation.xml b/DOCS/xml/en/documentation.xml index 8d4a5e38a4..2d6e16c4c2 100644 --- a/DOCS/xml/en/documentation.xml +++ b/DOCS/xml/en/documentation.xml @@ -3,7 +3,7 @@ <application>MPlayer</application> - The Movie Player - + March 24, 2003 2000 @@ -17,6 +17,7 @@ 2008 2009 2010 + 2011 MPlayer team @@ -45,116 +46,17 @@ If you are a first-time installer: be sure to read everything from here to the end of the Installation section, and follow the links you will find. If you have any other questions, return to the Table of Contents and search for the topic, read the , -or try grepping through the files. Most questions should be answered somewhere -here and the rest has probably already been asked on our -mailing lists. -Check the -archives, there -is a lot of valuable information to be found there. +or try grepping through the files. Introduction - - -MPlayer is a movie player for Linux (runs on -many other Unices, and non-x86 CPUs, see ). -It plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, -NuppelVideo, yuv4mpeg, FILM, RoQ, PVA, Matroska files, supported by -many native, XAnim, RealPlayer, and Win32 DLL codecs. You can watch -Video CD, SVCD, DVD, 3ivx, RealMedia, Sorenson, Theora, -and MPEG-4 (DivX) movies, too. Another big -feature of MPlayer is the wide range of -supported output drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, -fbdev, AAlib, libcaca, DirectFB, but you can use GGI and SDL (and this way all -their drivers) and some low level card-specific drivers (for Matrox, 3Dfx and -Radeon, Mach64, Permedia3) too! Most of them support software or hardware -scaling, so you can enjoy movies in fullscreen. -MPlayer supports displaying through some -hardware MPEG decoder boards, such as the DVB and -DXR3/Hollywood+. And what about the nice big -antialiased shaded subtitles (14 supported types) -with European/ISO 8859-1,2 (Hungarian, English, Czech, etc), Cyrillic, Korean -fonts, and the onscreen display (OSD)? - - +OUTDATED CONTENT REMOVED -The player is rock solid playing damaged MPEG files (useful for some VCDs), -and it plays bad AVI files which are unplayable with the famous -Windows Media Player. -Even AVI files without index chunk are playable, and you can -temporarily rebuild their indexes with the option, or -permanently with MEncoder, thus enabling -seeking! As you see, stability and quality are the most important things, -but the speed is also amazing. There is also a powerful filter system for -video and audio manipulation. - -MEncoder (MPlayer's Movie -Encoder) is a simple movie encoder, designed to encode -MPlayer-playable movies -AVI/ASF/OGG/DVD/VCD/VOB/MPG/MOV/VIV/FLI/RM/NUV/NET/PVA -to other MPlayer-playable formats (see below). -It can encode with various codecs, like MPEG-4 (DivX4) -(one or two passes), libavcodec, -PCM/MP3/VBR MP3 audio. - - - -<application>MEncoder</application> features - - Encoding from the wide range of file formats and decoders of - MPlayer - - - Encoding to all the codecs of FFmpeg's - libavcodec - - - Video encoding from V4L compatible TV tuners - - - Encoding/multiplexing to interleaved AVI files with proper index - - - Creating files from external audio stream - - - 1, 2 or 3 pass encoding - - - VBR MP3 audio - - - PCM audio - - - Stream copying - - - Input A/V synchronizing (pts-based, can be disabled with - option) - - - fps correction with option (useful when encoding - 30000/1001 fps VOB to 24000/1001 fps AVI) - - - Using our very powerful filter system (crop, expand, flip, postprocess, - rotate, scale, RGB/YUV conversion) - - - Can encode DVD/VOBsub and text subtitles - into the output file - - - Can rip DVD subtitles to VOBsub format - - - MPlayer and MEncoder diff --git a/DOCS/xml/en/encoding-guide.xml b/DOCS/xml/en/encoding-guide.xml index 9309df9df7..d458f31b1c 100644 --- a/DOCS/xml/en/encoding-guide.xml +++ b/DOCS/xml/en/encoding-guide.xml @@ -3,5550 +3,7 @@ Encoding with <application>MEncoder</application> - -Making a high quality MPEG-4 ("DivX") - rip of a DVD movie - - -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 do not care about file size, I just want the best -quality." - - - -The latter question is perhaps at least somewhat wrongly posed. After all, if -you do not 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 do not care about size, -this is certainly your best option. - - - -In fact, the reason you want to transcode a DVD into MPEG-4 is -specifically because you do care about -file size. - - - -It is difficult to offer a cookbook recipe on how to create a very high -quality DVD rip. There are several factors to consider, and you should -understand these details or else you are likely to end up disappointed -with your results. Below we will investigate some of these issues, and -then have a look at an example. We assume you are using -libavcodec to encode the video, -although the theory applies to other codecs as well. - - - -If this seems to be too much for you, you should probably use one of the -many fine frontends that are listed in the -MEncoder section -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. - - - - - -Preparing to encode: Identifying source material and framerate - - -Before you even think about encoding a movie, you need to take -several preliminary steps. - - - -The first and most important step before you encode should be -determining what type of content you are dealing with. -If your source material comes from DVD or broadcast/cable/satellite -TV, it will be stored in one of two formats: NTSC for North -America and Japan, PAL for Europe, etc. -It is important to realize, however, that this is just the formatting for -presentation on a television, and often does -not correspond to the -original format of the movie. -Experience shows that NTSC material is a lot more difficult to encode, -because there more elements to identify in the source. -In order to produce a suitable encode, you need to know the original -format. -Failure to take this into account will result in various flaws in your -encode, including ugly combing (interlacing) artifacts and duplicated -or even lost frames. -Besides being ugly, the artifacts also harm coding efficiency: -You will get worse quality per unit bitrate. - - - - -Identifying source framerate - - -Here is a list of common types of source material, where you are -likely to find them, and their properties: - - - - - Standard Film: Produced for - theatrical display at 24fps. - - - PAL video: Recorded with a PAL - video camera at 50 fields per second. - A field consists of just the odd- or even-numbered lines of a - frame. - Television was designed to refresh these in alternation as a - cheap form of analog compression. - The human eye supposedly compensates for this, but once you - understand interlacing you will learn to see it on TV too and - never enjoy TV again. - Two fields do not make a - complete frame, because they are captured 1/50 of a second apart - in time, and thus they do not line up unless there is no motion. - - - NTSC Video: Recorded with an - NTSC video camera at 60000/1001 fields per second, or 60 fields per - second in the pre-color era. - Otherwise similar to PAL. - - - Animation: Usually drawn at - 24fps, but also comes in mixed-framerate varieties. - - - Computer Graphics (CG): Can be - any framerate, but some are more common than others; 24 and - 30 frames per second are typical for NTSC, and 25fps is typical - for PAL. - - - Old Film: Various lower - framerates. - - - - - - -Identifying source material - - -Movies consisting of frames are referred to as progressive, -while those consisting of independent fields are called -either interlaced or video - though this latter term is -ambiguous. - - - -To further complicate matters, some movies will be a mix of -several of the above. - - - -The most important distinction to make between all of these -formats is that some are frame-based, while others are -field-based. -Whenever a movie is prepared -for display on television (including DVD), it is converted to a -field-based format. -The various methods by which this can be done are collectively -referred to as "telecine", of which the infamous NTSC -"3:2 pulldown" is one variety. -Unless the original material was also field-based (and the same -fieldrate), you are getting the movie in a format other than the -original. - - - -There are several common types of pulldown: - - PAL 2:2 pulldown: The nicest of - them all. - Each frame is shown for the duration of two fields, by extracting the - even and odd lines and showing them in alternation. - If the original material is 24fps, this process speeds up the - movie by 4%. - - - PAL 2:2:2:2:2:2:2:2:2:2:2:3 pulldown: - Every 12th frame is shown for the duration of three fields, instead of - just two. - This avoids the 4% speedup issue, but makes the process much - more difficult to reverse. - It is usually seen in musical productions where adjusting the - speed by 4% would seriously damage the musical score. - - - NTSC 3:2 telecine: Frames are - shown alternately for the duration of 3 fields or 2 fields. - This gives a fieldrate 2.5 times the original framerate. - The result is also slowed down very slightly from 60 fields per - second to 60000/1001 fields per second to maintain NTSC fieldrate. - - - NTSC 2:2 pulldown: Used for - showing 30fps material on NTSC. - Nice, just like 2:2 PAL pulldown. - - - - -There are also methods for converting between NTSC and PAL video, -but such topics are beyond the scope of this guide. -If you encounter such a movie and want to encode it, your best -bet is to find a copy in the original format. -Conversion between these two formats is highly destructive and -cannot be reversed cleanly, so your encode will greatly suffer -if it is made from a converted source. - - - -When video is stored on DVD, consecutive pairs of fields are -grouped as a frame, even though they are not intended to be shown -at the same moment in time. -The MPEG-2 standard used on DVD and digital TV provides a -way both to encode the original progressive frames and to store -the number of fields for which a frame should be shown in the -header of that frame. -If this method has been used, the movie will often be described -as "soft-telecined", since the process only directs the -DVD player to apply pulldown to the movie rather than altering -the movie itself. -This case is highly preferable since it can easily be reversed -(actually ignored) by the encoder, and since it preserves maximal -quality. -However, many DVD and broadcast production studios do not use -proper encoding techniques but instead produce movies with -"hard telecine", where fields are actually duplicated in the -encoded MPEG-2. - - - -The procedures for dealing with these cases will be covered -later in this guide. -For now, we leave you with some guides to identifying which type -of material you are dealing with: - - - -NTSC regions: - - If MPlayer prints that the framerate - has changed to 24000/1001 when watching your movie, and never changes - back, it is almost certainly progressive content that has been - "soft telecined". - - - If MPlayer shows the framerate - switching back and forth between 24000/1001 and 30000/1001, and you see - "combing" at times, then there are several possibilities. - The 24000/1001 fps segments are almost certainly progressive - content, "soft telecined", but the 30000/1001 fps parts could be - either hard-telecined 24000/1001 fps content or 60000/1001 fields per second - NTSC video. - Use the same guidelines as the following two cases to determine which. - - - If MPlayer never shows the framerate - changing, and every single frame with motion appears combed, your - movie is NTSC video at 60000/1001 fields per second. - - - If MPlayer never shows the framerate - changing, and two frames out of every five appear combed, your - movie is "hard telecined" 24000/1001fps content. - - - - -PAL regions: - - If you never see any combing, your movie is 2:2 pulldown. - - - If you see combing alternating in and out every half second, - then your movie is 2:2:2:2:2:2:2:2:2:2:2:3 pulldown. - - - If you always see combing during motion, then your movie is PAL - video at 50 fields per second. - - - -Hint: - - MPlayer can slow down movie playback - with the -speed option or play it frame-by-frame. - Try using 0.2 to watch the movie very - slowly or press the "." key repeatedly to play one frame at - a time and identify the pattern, if you cannot see it at full speed. - - - - - - - - -Constant quantizer vs. multipass - - -It is possible to encode your movie at a wide range of qualities. -With modern video encoders and a bit of pre-codec compression -(downscaling and denoising), it is possible to achieve very good -quality at 700 MB, for a 90-110 minute widescreen movie. -Furthermore, all but the longest movies can be encoded with near-perfect -quality at 1400 MB. - - - -There are three approaches to encoding the video: constant bitrate -(CBR), constant quantizer, and multipass (ABR, or average bitrate). - - - -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. - - -Note: - -Most codecs which support ABR encode only support two pass encode -while some others such as x264, -Xvid -and libavcodec 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. - - - - -In each of these modes, the video codec (such as -libavcodec) -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.) - - - -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 - for -libavcodec, 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. - - - -With constant quantizer, the codec uses the same quantizer, as -specified by the option (for -libavcodec), on every macroblock. -If you want the highest quality rip possible, again ignoring bitrate, -you can use . -This will yield the same bitrate and PSNR (peak signal-to-noise ratio) -as CBR with -=infinity and the default -of 2. - - - -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. - - - -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. - - - -If you use , then you are wasting bits. If you -use , then you are not getting the highest -quality rip. Suppose you rip a DVD at , and -the result is 1800Kbit. If you do a two pass encode with -, the resulting video will have -higher quality for the -same bitrate. - - - -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. - - - -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. - - - -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 -rip those 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 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 - - - - - - -Constraints for efficient encoding - - -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 file size, it is -a bad idea to use dimensions that are not multiples of 16. - - - -Most DVDs also have some degree of black borders at the edges. Leaving -these in place will hurt quality a lot -in several ways. - - - - - - 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. - - - - 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. - - - - - -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: - - - - - - 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. - - - - Again, this problem only applies if black borders do not line up on - multiple-of-16 boundaries. - - - - - - 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. - - - - 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. - - - - - Despite the borders being entirely black and never changing, there - is at least a minimal amount of overhead involved in having more - macroblocks. - - - - -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. - - - - - - -Cropping and Scaling - - -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. - - - -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. - - - - - - - - - - - - - - - - - - - - - L - L - L - L - L - L - L - L - - - C - C - C - C - - - L - L - L - L - L - L - L - L - - - L - L - L - L - L - L - L - L - - - C - C - C - C - - - L - L - L - L - L - L - L - L - - - - - - -As you can see, rows and columns of the image naturally come in pairs. -Thus your crop offsets and dimensions must be -even numbers. -If they are not, the chroma will no longer line up correctly with the -luma. -In theory, it is possible to crop with odd offsets, but it requires -resampling the chroma which is potentially a lossy operation and not -supported by the crop filter. - - - -Further, interlaced video is sampled as follows: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Top field - Bottom field - - - L - L - L - L - L - L - L - L - - - - - - - - - - - C - C - C - C - - - - - - - - - - - - - - - - - - - L - L - L - L - L - L - L - L - - - L - L - L - L - L - L - L - L - - - - - - - - - - - - - - - - - - - C - C - C - C - - - - - - - - - - - L - L - L - L - L - L - L - L - - - L - L - L - L - L - L - L - L - - - - - - - - - - - C - C - C - C - - - - - - - - - - - - - - - - - - - L - L - L - L - L - L - L - L - - - L - L - L - L - L - L - L - L - - - - - - - - - - - - - - - - - - - C - C - C - C - - - - - - - - - - - L - L - L - L - L - L - L - L - - - - - - -As you can see, the pattern does not repeat until after 4 lines. -So for interlaced video, your y-offset and height for cropping must -be multiples of 4. - - - -Native DVD resolution is 720x480 for NTSC, and 720x576 for PAL, but -there is an aspect flag that specifies whether it is full-screen (4:3) or -wide-screen (16:9). Many (if not most) widescreen DVDs are not strictly -16:9, and will be either 1.85:1 or 2.35:1 (cinescope). This means that -there will be black bands in the video that will need to be cropped out. - - - -MPlayer provides a crop detection filter that -will determine the crop rectangle (). -Run MPlayer with - and it will print out the crop -settings to remove the borders. -You should let the movie run long enough that the whole picture -area is used, in order to get accurate crop values. - - - -Then, test the values you get with MPlayer, -using the command line which was printed by -, and adjust the rectangle as needed. -The filter can help by allowing you to -interactively position the crop rectangle over your movie. -Remember to follow the above divisibility guidelines so that you -do not misalign the chroma planes. - - - -In certain cases, scaling may be undesirable. -Scaling in the vertical direction is difficult with interlaced -video, and if you wish to preserve the interlacing, you should -usually refrain from scaling. -If you will not be scaling but you still want to use multiple-of-16 -dimensions, you will have to overcrop. -Do not undercrop, since black borders are very bad for encoding! - - - -Because MPEG-4 uses 16x16 macroblocks, you will want to make sure that each -dimension of the video you are encoding is a multiple of 16 or else you -will be degrading quality, especially at lower bitrates. You can do this -by rounding the width and height of the crop rectangle down to the nearest -multiple of 16. -As stated earlier, when cropping, you will want to increase the Y offset by -half the difference of the old and the new height so that the resulting -video is taken from the center of the frame. And because of the way DVD -video is sampled, make sure the offset is an even number. (In fact, as a -rule, never use odd values for any parameter when you are cropping and -scaling video.) If you are not comfortable throwing a few extra pixels -away, you might prefer to scale the video instead. We will look -at this in our example below. -You can actually let the filter do all of the -above for you, as it has an optional parameter that -is equal to 16 by default. - - - -Also, be careful about "half black" pixels at the edges. Make sure you -crop these out too, or else you will be wasting bits there that -are better spent elsewhere. - - - -After all is said and done, you will probably end up with video whose pixels -are not quite 1.85:1 or 2.35:1, but rather something close to that. You -could calculate the new aspect ratio manually, but -MEncoder offers an option for libavcodec called -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. - - - - - - -Choosing resolution and bitrate - - -If you will not be encoding in constant quantizer mode, you need to -select a bitrate. -The concept of bitrate is quite simple. -It is the (average) number of bits that will be consumed to store your -movie, per second. -Normally bitrate is measured in kilobits (1000 bits) per second. -The size of your movie on disk is the bitrate times the length of the -movie in time, plus a small amount of "overhead" (see the section on -the AVI container -for instance). -Other parameters such as scaling, cropping, etc. will -not alter the file size unless you -change the bitrate as well! - - - -Bitrate does not scale proportionally -to resolution. -That is to say, a 320x240 file at 200 kbit/sec will not be the same -quality as the same movie at 640x480 and 800 kbit/sec! -There are two reasons for this: - - - Perceptual: You notice MPEG - artifacts more if they are scaled up bigger! - Artifacts appear on the scale of blocks (8x8). - Your eye will not see errors in 4800 small blocks as easily as it - sees errors in 1200 large blocks (assuming you will be scaling both - to fullscreen). - - - Theoretical: When you scale down - an image but still use the same size (8x8) blocks for the frequency - space transform, you move more data to the high frequency bands. - Roughly speaking, each pixel contains more of the detail than it - did before. - So even though your scaled-down picture contains 1/4 the information - in the spacial directions, it could still contain a large portion - of the information in the frequency domain (assuming that the high - frequencies were underutilized in the original 640x480 image). - - - - - -Past guides have recommended choosing a bitrate and resolution based -on a "bits per pixel" approach, but this is usually not valid due to -the above reasons. -A better estimate seems to be that bitrates scale proportional to the -square root of resolution, so that 320x240 and 400 kbit/sec would be -comparable to 640x480 at 800 kbit/sec. -However this has not been verified with theoretical or empirical -rigor. -Further, given that movies vary greatly with regard to noise, detail, -degree of motion, etc., it is futile to make general recommendations -for bits per length-of-diagonal (the analog of bits per pixel, -using the square root). - - -So far we have discussed the difficulty of choosing a bitrate and -resolution. - - - - -Computing the resolution - - -The following steps will guide you in computing the resolution of your -encode without distorting the video too much, by taking into account several -types of information about the source video. -First, you should compute the encoded aspect ratio: -ARc = (Wc x (ARa / PRdvd )) / Hc - - -where: - - Wc and Hc are the width and height of the cropped video, - - - ARa is the displayed aspect ratio, which usually is 4/3 or 16/9, - - - PRdvd is the pixel ratio of the DVD which is equal to 1.25=(720/576) for PAL - DVDs and 1.5=(720/480) for NTSC DVDs. - - - - - -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 -and -ResX = INT( ResY * ARc / 16) * 16 - - - -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 is a limited total number of bits that you can spend; therefore it is -necessary to find a good tradeoff between compressibility and quality. - - - -The CQ depends on the bitrate, the video codec efficiency and the -movie resolution. -In order to raise the CQ, typically you would downscale the movie given that the -bitrate is computed in function of the target size and the length of the -movie, which are constant. -With MPEG-4 ASP codecs such as Xvid -and libavcodec, a CQ below 0.18 -usually results in a pretty blocky picture, because there -are not 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 are not enough bits, the edges of those blocks are -visible.) -It is 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 rip with standard encoding options. -More advanced encoding options such as those listed here for -libavcodec -and -Xvid -should make it possible to get the same quality with CQ ranging from -0.18 to 0.20 for a 1 CD rip, and 0.24 to 0.26 for a 2 CD rip. -With MPEG-4 AVC codecs such as x264, -you can use a CQ ranging from 0.14 to 0.16 with standard encoding options, -and should be able to go as low as 0.10 to 0.12 with -x264's advanced encoding settings. - - - -Please take 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 is worthless to raise CQ higher than 0.30 as you would -be wasting bits without any noticeable quality gain. -Also note that as mentioned earlier in this guide, low resolution videos -need a bigger CQ (compared to, for instance, DVD resolution) to look good. - - - - - - - -Filtering - - -Learning how to use MEncoder's video filters -is essential to producing good encodes. -All video processing is performed through the filters -- cropping, -scaling, color adjustment, noise removal, sharpening, deinterlacing, -telecine, inverse telecine, and deblocking, just to name a few. -Along with the vast number of supported input formats, the variety of -filters available in MEncoder is one of its -main advantages over other similar programs. - - - -Filters are loaded in a chain using the -vf option: - --vf filter1=options,filter2=options,... - -Most filters take several numeric options separated by colons, but -the syntax for options varies from filter to filter, so read the man -page for details on the filters you wish to use. - - - -Filters operate on the video in the order they are loaded. -For example, the following chain: - --vf crop=688:464:12:4,scale=640:464 - -will first crop the 688x464 region of the picture with upper-left -corner at (12,4), and then scale the result down to 640x464. - - - -Certain filters need to be loaded at or near the beginning of the -filter chain, in order to take advantage of information from the -video decoder that will be lost or invalidated by other filters. -The principal examples are (postprocessing, only -when it is performing deblock or dering operations), - (another postprocessor to remove MPEG artifacts), - (inverse telecine), and - (for converting soft telecine to hard telecine). - - - -In general, you want to do as little filtering as possible to the movie -in order to remain close to the original DVD source. Cropping is often -necessary (as described above), but avoid to scale the video. Although -scaling down is sometimes preferred to using higher quantizers, we want -to avoid both these things: remember that we decided from the start to -trade bits for quality. - - - -Also, do not adjust gamma, contrast, brightness, etc. What looks good -on your display may not look good on others. These adjustments should -be done on playback only. - - - -One thing you might want to do, however, is pass the video through a -very light denoise filter, such as . -Again, it is a matter of putting those bits to better use: why waste them -encoding noise when you can just add that noise back in during playback? -Increasing the parameters for will further -improve compressibility, but if you increase the values too much, you -risk degrading the image visibly. The suggested values above -() are quite conservative; you should feel free to -experiment with higher values and observe the results for yourself. - - - - - - -Interlacing and Telecine - - -Almost all movies are shot at 24 fps. Because NTSC is 30000/1001 fps, some -processing must be done to this 24 fps video to make it run at the correct -NTSC framerate. The process is called 3:2 pulldown, commonly referred to -as telecine (because pulldown is often applied during the telecine -process), and, naively described, it works by slowing the film down to -24000/1001 fps, and repeating every fourth frame. - - - -No special processing, however, is done to the video for PAL DVDs, which -run at 25 fps. (Technically, PAL can be telecined, called 2:2 pulldown, -but this does not become an issue in practice.) The 24 fps film is simply -played back at 25 fps. The result is that the movie runs slightly faster, -but unless you are an alien, you probably will not notice the difference. -Most PAL DVDs have pitch-corrected audio, so when they are played back at -25 fps things will sound right, even though the audio track (and hence the -whole movie) has a running time that is 4% less than NTSC DVDs. - - - -Because the video in a PAL DVD has not been altered, you need not worry -much about framerate. The source is 25 fps, and your rip