![[PukiWiki]](image/aviutl.png "[PukiWiki]")
書きかけ~ そのうちに日本語に…できるかな？~ *x264 Switches and Options [#u6c09280] そのうちに日本語に…できるかな？~ ~ [[Encoding H.264 using the x264 Command Line Interface:http://aflux.deltaanime.net/Zero1/MP4/x264.html#x264-switches-and-options]]~ #contents **Frame-type Options [#ge36a05a] ***--keyint [#de12a8c3] Usage: --keyint <integer> (default=250) This is the maximum GOP (Group Of Pictures) value. It controls the maximum number of frames allowed before a new IDR frame is forced and starts a new GOP. The equivalent to this that you would find in XviD would be "Maximum I-frame Interval". As a rule of thumb people tend to set this at 10 seconds worth of frames to aid seeking. For PAL @ 25 fps it would be --keyint 250, or for NTSC @ 23.976 fps we would just round up and use --keyint 240. A new GOP will usually begin at a scene change, unless the --keyint value is exceeded, so this only really applies for sources with long durations without a scene change or significant change in the image (which will almost never happen in an AMV). ***--min-keyint [#ue76209a] Usage: --min-keyint <integer> (default=25) This is the minimum GOP (Group Of Pictures) value. This specifies the minimum number of frames allowed before a new IDR frame and GOP is forced. If a scene change happens within the --min-keyint value, it will simply code the first frame of the scene change as an I frame and prevent it from starting a new GOP. ***--scenecut [#d41f0464] Usage: --scenecut <integer> (default=40) [1 - 100] Scenecut is the threshold for inserting extra I-frames. Setting a high value will cause it to use I-frames where they perhaps aren't needed (and in turn waste bits), for example a considerable change in the image, but not significant enough to be considered a scene change. Setting the value lower will use fewer I-frames and will rely more on the --keyint value which may end up in non optimal placement of I-frames, for instance you might get a very large P-frame at scene change instead of an I-frame (and P-frames require previous I or P frames to be decoded). ***--bframes [#kf328900] Usage: --bframes <integer> (default=0) [0 - 16] This simply controls the maximum number of consecutive B-frames between I and P frames. You will be familliar with B-frames from using XviD (and perhaps other MPEG encoders). The same option in XviD is reffered to as "Max consecutive B-VOPs". While B-frames are very nice from a coding efficiency point of view, bear in mind that the more get used, the higher the decoding requirements will be. ***--no-b-adapt [#i892f5ee] Usage: --no-b-adapt (default=on) This option disables adaptive B-frame decision and is generally not recommended. When not disabled (it's enabled by default and --no-b-adapt turns it off) this allows the encoder to automatically decide where B-frames will be used and how many. How many B-frames adaptive B-frame decision will use is defined by --bframes as above. ***--b-bias [#mb59a830] Usage: --b-bias <integer> (default=0) [-100 - 100] ~--b-bias affects adaptive B-frame decision. A higher number will result in using more B-frames up to the specified maximum and the lower number will use less B-frames. There is a similar option to this in XviD called B-VOP sensitivity. You can visualise this as a slider, with -100 at the left with a label "Use less B-frames" and 100 on the right labelled "Use more B-frames". It is recommended to leave --b-bias at 0 (or simply leave it out from your script) since forcing B-frames can be sub-optimal, particularly with trouble sources like dark areas or flames. ***--b-pyramid [#n2bd7f58] Usage: --b-pyramid (default=off) This allows the encoder to use some B-frames as references. This should help increase efficiency since other frames can now be predicted using B-frames. This feature requires 2 or more B-frames, and may cause a 2 frame decoder lag. This feature is disabled by default and is enabled by adding --b-pyramid to the command line. ***--no-cabac [#l70e543b] Usage: --no-cabac (default=on) CABAC (Context-Adaptive Binary Arithmetic Coding) is an entropy encoder. What it does is take the macroblock information, their headers, textures, motion vectors and compresses it to the bitstream losslessly. CABAC can save approximately 10% on bitrate, and possibly more for anime. The downside is that it increases encoding and decoding requirements, however a 10% bitrate reduction is a significant advantage considering it doesn't degrade quality. ***--ref [#f4e02f36] Usage: --ref <integer> (default=1) [1 - 16] This is for setting the number of reference frames. It allows new P and B frames to be predicted by using a previously decoded frames (up to the number specified in --ref). Setting a higher value will increase efficiency up to a point. Naturally this is a very beneficial feature for anime since you often get many similar frames say for when a character is speaking and only the mouth is changing, or for loops where something is repeated like hair swaying in the wind. ***--nf [#wd841d93] Usage: --nf (default=on) Disables inloop deblocking. Read --filter below for more information ***--filter [#x446af67] Usage: --filter <alpha:beta> (default=0:0) [-6:-6 - 6:6] The inloop deblocking usually improves compressability and therefore quality. If you do not like the effect simply turn it down. What it tends to do is smooth an image as opposed to letting it block in high motion areas like you may have seen in XviD. The AlphaC0 parameter controls the strength, and Beta controls the threshold. The default value of 0:0 is thought to be optimal, although Sharktooth has suggested to me that anime would look good at 3:3. Experiment on short varied clips and see what works for you. **Rate Control [#nedaa658] ***--qp [#td2da65b] Usage: --qp <integer> (default=26) [1 - 51] (0 = Lossless) This sets a constant P-frame quantizer. The quantizer for I and B-frames are then calculated by the QP factor set in --ipratio and --pbratio. As with XviD, the lower the quantizer, the higher the quality, but this one of the features that I warned you about. QP 2 in x264 is NOT like QP 2 in XviD, in fact the equivalent to XviD's QP 2 in x264, is QP 18. This is owing to H.264 using a logarithmic scale. The formula to find the approximate equivalent QP is as follows: QP AVC qp = 12 + 6*log2(ASP qp). x264 is also capable of lossless encoding, to enable this mode set the QP to 0. ***--bitrate [#l04b1218] Usage: --bitrate <integer> (default=off) Allows you to specify an average bitrate in kilobits per second (Kbps). If you are trying to meet a filesize, it is recommended you use 2 pass encoding, this will increase quality as well as help you meet the target bitrate. For short clips around 1 minute or less, a third pass may be beneficial. x264's --bitrate is inherently ABR, if you must use CBR (there are few goods reasons for this other than streaming) then you will need to change the --vbv-maxrate accordingly. ***--crf [#waa4c79f] Usage: --crf <integer> (default=off) [1 - 51] Constant Rate Factor. This is a one pass VBR mode based on a nominal QP. ***--qpmin [#cc8c70df] Usage: --qpmin <integer> (default=10) [1 - 51] Simply sets the minimum quantizer that x264 is allowed to use. This will prevent bit squandering where using a higher quantizer makes little or no visual difference. This is similar to using XviD in as much that you used to cap the minimum quantizers at 2, but do bear in mind the differences in quantization with H.264. ***--qpmax [#e4a624a9] Usage: --qpmax<integer> (default=51) [1 - 51] Sets the maximum quantizer that x264 is allowed to use. You can cap this if you find that some frames are being quantized too high for your liking. In general the ratecontrol of x264 is very good and won't tend to use insanely high or low quants. ***--qpstep [#w70f379b] Usage: --qpstep <integer> (default=4) [1 - 50] This controls the maximum amount by which the quantizer may change between frames. Setting a large value will in theory allow the quantizer to fluctuate more between frames, in turn producing a large variation in quality in a short time. ***--ratetol [#r4689a32] Usage: --ratetol <float> (default=1.0) [0.1 - 100.0] Defines the allowed deviation in the average bitrate. Setting it higher than 1.0 may result in files larger than your target, and likewise setting it less than 1.0 may result in undersized files. ***--ipratio [#qc79a682] Usage: --ipratio <float> (default=1.40) Defines the quantizer factor between I and P frames. Setting this to 1.00 will mean that P frames will get the same quantizer as I frames which is not recommended because it amounts to wasting bits. You could try setting this above 1.40 if you find your AMV isn't making much use of B-frames, this should decrease the quality of the P-frames (how much is dependant on the --ipratio) but in turn result in a more consistant quality, as opposed to it fluctuating and blocking in high motion areas etc. ***--pbratio [#td8a9e46] Usage: --pbratio <float> (default=1.30) Sets the quantizer factor between P and B frames. Again, setting to 1.00 will cause B frames to be quantized the same amount as P frames, and therefore is --ipratio is set at 1.00, I, P and B-frames will all be quantized equally. In general you can compress B frames even more than P frames, so you might want to try values higher than 1.30, particularly if you enable --brdo (VHQ for B-frames). I, P and B-frame usage is printed in the console when the encode is complete. ***--chroma-qp-offset [#o92e7d93] Usage: --chroma-qp-offset <integer> (default=0) [-12 - 12] Allows you to use a different quantizer for Chroma as opposed to Luma. This is an interesting option because it allows you to exploit the human visual system, since it is more sensitive to changes in luma than chroma. The downside though, is because the chroma has less information to start with, what with it being subsampled for YV12, is that you have to sacrifice a lot of chroma quality in return for a little luma quality. ***--pass [#c738cb39] Usage: --pass <1|2|3> This is where you enable multi pass mode. In addition to first and second pass as you will be familliar with from using XviD, it also features "nth pass". This means that you can run a first pass to collect the stats, then run the nth pass to give you the second pass. If you are not happy with the results, or are not meeting the filesize, you can run the settings you used for the second pass again, and nth pass now does a pass 3. Nth pass works by updating the stats file each time, 2nd pass just performs a final pass and doesn't update the stats. - --pass 1~ Pass 1 is the where the video is analysed and the stats are written to a file. This is just like the "2 pass - First pass" mode in XviD. By default this outputs a muxable file that you can use. If you specify the bitrate at this stage it will produce a 1 pass ABR, if you use --qp 18 instead, it will output a file which should be visually the same as XviD's full quality first pass mode. Specifying the target bitrate at this stage as opposed to using --qp 18 will usually result in a better quality 2nd and nth pass. - --pass 2~ Pass 2 generates output based on the complexity stats collected by the first pass, and makes ratecontrol decisions based on this. This mode is equivalent to "2 pass - Second pass" in XviD, and does not update or modify the stats file. 2 pass usually brings about higher quality and lower filesizes and is always recommended. To visualise how it works, see below.~ ~ (Pass 1) --pass 1 = Initial stats collection~ (Pass 2) --pass 2 = Output using Pass 1 stats~ - --pass 3~ ~--pass 3 is somewhat special. It isn't referred to as Second or Third pass, since the amount of passes you can do with it are infinate. The quality gain isn't, so don't go doing 10 pass encodes. It is really only useful for sources around 1000 frames or less where it doesn't have much time to average the bitrate properly. It essentially does the job of -pass 1 and --pass 2, but pass 1 is still required for initial stats collection. Instead of just reading from the stats file and providing output, it reads from the stats file, outputs and updates it. This means that if you do a 3 pass encode using the nth pass mode, it will be using refined stats from pass 2. The easy way to understand this is to visualise it.it will work from the stats from pass 1 that have been refined when you ran pass 2.~ ~ (Pass 1) --pass 1 = Initial stats collection~ (Pass 2) --pass 3 = Output using Pass 1 stats + update stats file~ (Pass 3) --pass 3 = Output using Pass 2 stats + update stats file~ ***--stats [#q3a5ad4b] Usage: --stats <string> (default="x264_2pass.log") Simply specify the location and file name of the log file to be used in multi pass encoding. All passes must refer to the same logfile otherwise it will not work correctly. ***--qcomp [#w5da865a] Usage: --qcomp <float> (default=0.60) [0.00 - 1.00] This is QP curve compression. Setting lower values will result in a more constant bitrate encode, 0.00 should be CBR. Higher values will result in a more constant QP encode. It is suggested to use the default of 0.60. Setting 0.00 for CBR is a very bad idea, especially for AMVs, because you cripple the encoders ability to use rate control, which saves bits in low motion/complexity areas, and re-allocates them to high motion/complexity areas. ***--cplxblur [#neb42431] Usage: --cplxblur <float> (default=20.0) [0 - 999] ~--cplxblur controls the temporal smoothing of the estimated frame complexity and is used to reduce fluctuations in QP over time before curve compression. Setting this value low will allow the QP to fluctuate more, and setting it high would cause the QP to vary smoothly. This option is only applicable for two and nth pass mode since it makes use of the stats file. Unless you understand this option, you should leave it at the default 20.0 ***--qblur [#o346b383] Usage: ---qblur <float> (default=0.5) [0 - 99] Similar to --cplxblur in some ways, except it temporally smooths the quantisation paramater (QP). Again, low values will allow the QP to vary more, and high values will make it vary more smoothly. This is also something that you probably will not have cause to change, but is here for those that may benefit from some experimentation. ***--zones [#rd9ea3f1] Usage: --zones <zone0>/<zone1>/... (default=off) [b=0.01 - 100.0, q=0 - 51] Zones allows you to override bitrate or quantizer at a certain point in the video. A zone is specified as: Start frame, End frame, Option Options are q=<integer> (forced QP) or b=<float> (bitrate multiplier). To start a new zone you need a "/" before the new one begins. To see an example: --zones 200,900,b=0.50/1000,1200,b=2.0 This means that frames 200 through to 900 will use approximately half the specified average bitrate, and frames 1000 to 1200 will use twice the average bitrate. **Analysis [#e020b5c5] ***--analyse [#o44b7866] Usage: --analyse <string> (default=p8x8,b8x8,i8x8,i4x4) [p8x8, p4x4, b8x8, i8x8, i4x4, none, all] This sets the macroblock types that will be available when encoding. It is better to have more if not all of these modes enabled so as to allow the encoder to make a better decision when encoding, for instance large blocks of motion with little detail can be assigned 16x16 macroblocks, and fine detail can go right down to 4x4. It basically amounts to more efficient coding of macroblocks. The usefulness of some of these modes is dependant on the subpixel motion estimation used. p4x4 requires p8x8. i8x8 requires --8x8dct. ***--direct [#c0dbc9fb] Usage: --direct <string> (default=temporal) [none, spatial, temporal, auto] ~--direct defines the motion predicition used for direct macroblocks. Temporal is usually the better choice since it uses the following P-frame for motion prediction, as opposed to spatial which relies on surrounding macroblocks and their motion. Selecting none will of course give lower quality, and surprisingly, lower speed. Auto is the automatic selection of temporal and/or spatial prediction. It is a slower mode, but it allows it to make the best choice and alternate between modes, as opposed to using one or the other. ***--weightb [#y3b4749b] Usage: --weightb (default=off) Weighted B Frame prediciton is a special mode that takes into account the distance of a B-frame, relative to the previous and next P-frames when making decisions, as opposed to simply averaging like it normally would. This means that the use of B-frames is restricted in places where they would normally look bad (ie, if it's too hard to predict the motion accurately). This mode requires more than 1 B-frame to become effective. ***--me [#hfcad4dc] Usage: --me <string> (default=hex) [dia, hex, umh, esa] This sets the Integer pixel motion estimation method. The options are as follows: dia: diamond search, radius 1 (fast) hex: hexagonal search, radius 2 umh: uneven multi-hexagon search esa: exhaustive search (slow) It is recommended to use hex or umh. umh and esa also have an additional parameter that controls the search radius, see --merange. ***--merange [#d529b060] Usage: --merange <integer> (default=16) [4 - 64] This is simply the setting for the radius of the umh and esa motion estimation modes. 16 and 32 are thought to be good values. ***--subme [#u00d1430] Usage: --subme <integer> (default=5) [1 - 7] Sets the sub pixel motion estimation algorithm.This is one of the speed vs quality settings. --subme 6 & 7 also introduce Rate Distortion Optimisation (RDO). --subme 6 or 7 is recommended if you have the CPU speed, if not use 5. ***--b-rdo [#s475a8e6] Usage: --b-rdo (default=off) ~--b-rdo is Rate Distortion Optimisation for B-frames. The equivalent to this would be VHQ B-frames in XviD. Requires --subme 6 or higher. ***--mixed-refs [#e0e42d8d] Usage: --mixed-refs (default=off) Allows each 8x8/16 macroblock partition to choose it's own reference frame as opposed to the whole macroblock using the same reference. This obviously results in improved efficiency at the cost of encoding speed. Decoder wise it will increase the RAM requirement (but the level of videos you will be creating won't require extorionate amounts even with a large amount of reference frames). This mode requires more than one reference frame, ie --ref 1 ***--no-chroma-me [#u10b5014] Usage: --no-chroma-me (default=off) Disables chroma motion estimation. Chroma ME is performed during the subpixel motion estimation search and should ideally be left enabled. For chroma ME to be enabled, this switch must not be used, and --subme must be 5 or higher. ***--bime [#rf3cd481] Usage: --bime (default=off) ~--bime is the switch to enable joint bidirectional motion estimation refinement. It will optimise both motion vectors in B-frames. It will help increase the quality at the cost of encode time, and will have no effect on the decoder, so this is another one of those "free quality upgrades". ***--8x8dct [#ybe79b00] Usage: --8x8dct (default=off) Adaptive spatial transform size. This will allow the encoder to choose from 8x8 dct in addition to 4x4dct. This must be enabled to use the i8x8 macroblock type as mentioned in --analyse. Note: Using this feature makes the stream fall into the High Profile category, so make sure decoders and player support High Profile, or at least this feature. ***--trellis [#obe67516] Usage: --trellis <integer> (default=off) [0 - 2] Trellis is RDO, Rate Distortion Optimisation. It attempts to always make an optimal decision for Rate Distortion, and it lowers quality in some areas which will free up bits that can be used in more noticable areas if it considers the loss to be worth it. Think of it as fine tuning. --trellis 1 enables trellis on the final encode of a Macroblock, whereas --trellis 2 is enabled on all mode decisions, and therefore stands to save more bits which when using a target bitrate can lead to slightly higher quality. It requires CABAC, so it will not work with CAVLC. To use CAVLC instead of CABAC, --no-cabac must be specified. CABAC is enabled by default and gives you approximately 10% bitrate saving over CAVLC, but requires a little more CPU power to decode. ***--no-fast-pskip [#nf346505] Usage: --no-fast-pskip (default=off) No fast P-skip will disable early skip detection on P-frames. At the cost of encoding time, this should help reduce or eliminating blocking in blue areas (such as skies). The Adaptive Quantisation feature by Haali was designed as a workaround for blocking in blue areas, so if --no-fast-pskip doesn't help much, you should try Adaptive Quantisation. ***--aq-strength [#p2da369e] Usage: --aq-strength <float> (default=0.0) One part of the settings for Adaptive Quantisation. Adaptive Quantisation allows different parts of a frame to use different quantisers, as opposed to the whole frame using the same quantizer. The common use for this in XviD was that it would compress light and dark areas more, thus freeing bits for parts that were more noticable. Adaptive Quantisation works differently in x264 because it was added by Haali to address a problem that large blue areas could sometimes look blocky. Adaptive Quantisation in x264 assigns more bits to dark and blue areas to help stop them blocking up. This particular setting instructs the amount to adjust QP per Macroblock. Setting 0.0 is no Adaptive Quantisation, and 1.1 is considered strong. It is recommended that you only use this setting if your source is particularly blocky in blue areas only wheras the rest of the image looks fine. ***--aq-sensitivity [#a9998885] Usage: --aq-sensitivity <float> (default=15.0) This switch is to be used in conjunction with --aq-strength, and will not work if --aq-strength is set to 0.0, or not specified (since it is disabled by default). This controls the "flatness" threshold at which to apply AQ (Adaptive Quantisation). Setting it to 5 will apply AQ to almost all blocks, and setting it to 22 will apply it only to flat blocks. A flat block would be described as an area of solid colour or little detail. ***--nr [#h1922c3f] Usage: --nr <integer> (default=0) [0 - 1000] ~--nr is DCT domain noise reduction using a Wiener filter. This should be faster than an equivalent AVISynth filter. Useful values are 100-200. It is applied to the source before compression, and isn't a part of the H.264 standard, so it doesn't increase playback requirements or need any additional decoder functionality (it's just filtering, similar to what you could do in AVISynth). ***--cqm [#t7a645ea] CQM is the abbreviation for Custom Quantisation Matrix (or Matrices). A quantisation matrix is made up from a grid of numbers and each one is referred to as a quantum. It is these numbers that define how image data is discarded. A grid with large quantums will produce a softer image, and a grid with lower quantums will retain more detail. x264 by default uses a "flat 16" matrix, which is simply a matrix with all quantums set at 16 and does not require any special decoding. In contrast to this, custom quantisation matrices are a high profile feature and require special decoding support, though the actual decoding of them should require no more or no less resources. You might remember custom matrices from XviD, for most cases the default H.263 quantisation type worked fine, and in the case of x264, flat 16 is probably fine most of the time. In some cases you might want to use a matrix with a lot of high quantums in the high frequency co-efficient areas so that fine details become smoothed slightly and easier to compress.~ ~ There are numerous ways to define what CQM you want to use, here are the options available: ***--cqm <string> (Presets=jvt, flat) [#gbe250e9] This allows you to select the flat matrix (which is default) or the included JVT matrix (the matrix produced by the Joint Video Team, who is a joint partner in H.264). This is fairly simple to use and the matrices are included in the x264 executable so no external files are required. ***--cqmfile <string> [#q14cccb1] This option is probably the more practical of the rest when wanting to use a custom matrix. This will allow you to load an external matrix file. The file must be JM compatible (JM is the reference encoder). You can find a collection of external matrix files here at doom9. ***--cqm4 <list> [#j9cd45e0] Sets all 4x4 quantisation matrices. The input must be a comma seperated list of 16 integers. This might be good for experimenting but your command line could quickly become very long, especially when defining other quantisation matrices as well. ***--cqm8<list> [#cf9ada18] As before, but this sets all the 8x8 quantisation matrices. This must be a comma seperated list of 64 integers. ***--cqm4i, --cqm4p, --cqm8i, --cqm8p [#p9dc16ec] Allows you to set luma and chroma quantisation matrices. ***--cqm4iy, --cqm4ic, --cqm4py, --cqm4pc [#ce06d0c6] Allows you to set the individual quantisation matrices.~ ~ Video Usability Info ***--sar [#w1ca43bf] Usage: --sar <numerator:denominator> (default=1:1) [1 - 255] SAR means Sample Aspect Ratio. Setting this allows anamorphic video to be played back at the correct aspect ratio since the video is stretched on playback. Note that SAR does not work by specifying the aspect ratio, it works specifiying the factor to be stretched by. For example 32:27 is the SAR to make 720x480 video play back at 16:9 aspect ratio. This is because 32/27=1.185185.... Therefore 1.185185...x720 = 853.3r. You now have 853x480.~ ~ You will probably have encountered anamorphic video before, it's widescreen material that is usually squashed into a 4:3 frame size for example 720x480 which is NTSC 4:3 for DVDs.~ ~ There are a number of ways you might have dealt with anamorphic material in the past, you might have resized to 640x360 (and cropped to 352 for mod16), or some people might have resized to 852x480 (848 for mod 16). With the first method you lose a lot of detail, the second wastes data because you are upsizing the image. Anamorphic allows you to encode it as 720x480 or 704x480 and set the tag for it to be stretched on playback. The result is a video that will be resized to approx 853x480 on playback (may depend on the player), but will only require the equivalent amount of data as a 720x480 or 704x480 encode. This way you save bits since you aren't encoding an upscaled image, and save quality because you aren't downscaling. The playback requirements are also lower than the upscaled encode. SAR is goon in theory, but editing AMVs at the wrong aspect ratio whilst bearing in mind that it will be resized may be tricky, unless your editing software has some sort of mode to help with this.~ ~ Here are some common SARs:~ |Source Resolution|Display Aspect Ratio|Sample Aspect Ratio|h |720x480 (NTSC)|CENTER:1.33|CENTER:8:9| |CENTER:〃|CENTER:1.77|CENTER:32:27| |CENTER:〃|CENTER:1.85|CENTER:100:81| |CENTER:〃|CENTER:2.35|CENTER:69:44| |704x480 (NTSC Crop)|CENTER:1.33|CENTER:10:11| |CENTER:〃|CENTER:1.77|CENTER:40:33| |CENTER:〃|CENTER:1.85|CENTER:125:99| |CENTER:〃|CENTER:2.35|CENTER:85:53| |720x576 (PAL)|CENTER:1.33|CENTER:16:15| |CENTER:〃|CENTER:1.77|CENTER:64:45| |CENTER:〃|CENTER:1.85|CENTER:40:27| |CENTER:〃|CENTER:2.35|CENTER:32:17| |704x576 (PAL Crop)|CENTER:1.33|CENTER:12:11| |CENTER:〃|CENTER:1.77|CENTER:16:11| |CENTER:〃|CENTER:1.85|CENTER:50:33| |CENTER:〃|CENTER:2.35|CENTER:102:53| ~ If for instance I had a 704x480 video (720x480 NTSC after cropping the black bars) and is a 16:9 video, I would set --sar 40:33. You may also set the SAR in MP4box (recommended). You can check out the MP4box guide for muxing. ***--overscan [#z022956a] Usage: --overscan <string> (default=undef) [undef, show, crop] As you should know from reading the guides, editing or viewing, a TV does not show the complete image, in fact you "lose" between 10% and 20%. The reason for this is to prevent blank space being displayed on the screen, and so giving you full use of the tube. Overscan is good in some respects since for NTSC, 525 lines are transmitted, but only approximately 486 lines contain active image data. If you didn't have overscan, your TV would display all 525 lines meaning you would have black borders at the top and bottom. The sides of the image usually contain blank data too. This is common in DVD where the active image is approximately 704-711 "pixels" wide, but black area is added in to make the resolution 720 pixels wide (this is because MPEG-2 requires resolutions divisible by 16 for the horizontal resolution). So what happens if your video does not contain overscan? Well your image will effectively appear cropped (since you lose some of the image due to overscan). This is where the --overscan switch can help out. Setting "--overscan show" will mean the image is zoomed out to show you the full image, so now it's not getting cropped. Setting this option to "crop" will mean you lose the image as you would normally do. This setting requires compatible hardware (or software, but PC screens do not overscan anyway), if the feature is not implemented, it will simply be ignored and cropped as usual regardless of what you set. ***--videoformat [#bc9f30b0] Usage: --videoformat <string> (default=undef) [component, pal, ntsc, secam, mac, undef] This is just an informative setting, kind of like meta data about the file. It allows you to set the source. Since it is for information only, it doesn't influence playback or encoding at all. ***--fullrange [#lcf3cb8b] Usage: --fullrange <string> (default=off) [on, off] This is another setting primarily aimed at TV sets. TV sets assume that the luma range is 16-235, and chroma is 16-240. This looks Ok on a TV set, but on a PC screen black will appear dark grey, and white, light grey. In this case, you might choose to fix the levels in AVISynth if you intend your AMV to be viewed on a PC screen. Even if you are unaware of this fact, you might be using effects in your AMV that do not fall within 16-235 (ie if you use pure black, pure white, or pure saturated colours). Add to that, some DVDs use the full 0-255 range also. So what is the problem with using a full 0-255 range on a TV? Well in addition to it being incorrect by standards, it will look oversaturated . You can "fix" this by using "--fullrange on". It corrects the range on playback (it scales it from 0-255 to 16-235), so by using fullrange it will look correct on a TV (assuming you are using a H.264 capable hardware player). Since PC monitors are capable of 0-255 (and above), it's likely that software players will ignore this option and so it won't be rescaled; meaning you get the correct 0-255 output. The video now looks correct on both devices. You can set "--fullrange off" only if you can make sure your range is already limited to 16-235. ***--chromaloc [#p232f001] Usage: --chromaloc <integer> (default=0) [0 - 5] This is a very technical setting. It is to do with upsampling of the chroma, for example colourspace conversions, or playback. When done correctly, it should help prevent chroma shift or blurring (though the shift isn't significant, only perhaps 1 pixel at most). If you are editing AMVs however, you have already done a colourspace conversion when you edited the video (since most video editing programs work in RGB), so it perhaps isn't even worth setting this (not to mention the average person wouldn't notice a difference). I would advise against setting this unless it is a direct transcode with no colourspace conversions. For completeness though, here is a rule of thumb: >If the source is MPEG-1 (4:2:0) and is a direct transcode (no colourspace conversion), set this to 1. If the source is MPEG-2 (4:2:0) and is a direct transcode (no colourspace conversion), set this to 0. If the source is MPEG-4 (4:2:0) and is a direct transcode (no colourspace conversion), set this to 0. **Input/Output [#z2151dc3] ***--level [#n7855ac2] Usage: --level <string> Level allows you to set the Profile@Level as defined by Annex A. It is this level which hardware players will check against to see if the file is playable. x264 automatically sets the highest profile and is not recommended you change it unless you know that your video falls within a certain Profile@Level, or you otherwise know what you are doing. You can find a graph of levels and the maximum supported values by clicking the thumbnail, be warned that it is very technical though.~ ~ [[&ref("h264levels2.png",nolink);>http://www.tenchi.ne.jp/~yoko/aviutl/index.php?plugin=attach&pcmd=open&file=h264levels.png&refer=x264%A5%AA%A5%D7%A5%B7%A5%E7%A5%F3]] ***--fps [#pabdfdba] Usage: --fps <float|rational> Quite self explanatory, this sets the framerate of the video. You can specify this as a floating point number, for example --fps 23.976 or a rational number such as 24000/1001. Note that these will produce similar, but not the same framerates. This will be important if you intend to join segments at any time. The rational number is more accurate and is considered the true way of specifying 23.976 and 29.97 fps, 24000/1001 and 30000/1001 respectively. ***--seek [#x1bc2615] Usage: --seek <integer> Seek tells x264 at what frame to begin encoding. This is useful if you want to skip the first part of a file for example if it has a bumper that you decide you don't want to encode. This is somewhat similar to the Trim function in AVIsynth and can be used with --frames. ***--frames [#j2973a32] Usage: --frames <integer> This specifies the number of frames to encode, rather than encoding a whole video. You can use this with --seek to encode a certain part of a file for a certain amount of frames. ***--output [#v1449c7d] Usage: --output You use this to set the output path and filename. An important thing to remember is that this is where you specify the type of output too. Setting the extension to .264 will produce a raw MPEG-4 stream, setting .MP4 will create a video only MP4 (audio must be muxed later with MP4box) or setting .MKV will output a Matroska Video. If you are familliar enough with MKV you can output to MKV and take it from there, for the purpose of this guide we will output .264 and mux everything later, or you may output .MP4 for previewing purposes ***--threads [#t4d2ded1] Usage: --threads <integer> Parralell encoding using slices. If you have a multi CPU or multi core CPU, this will allow you a speed gain. Due to how threading and video coding works, using threads will lead to a very slight degredation of quality, but with the extra speed you gain you can just crank up the settings a bit and offset your loss and still have a speed gain. You use 1 thread for each CPU and/or core, so for dual core it would be --threads 2, or for a dual core dual CPU it would be --threads 4. ***--threads-input [#w5d11a0b] Usage: --threads <integer> Parralell encoding using one thread for the encoding, and another thread for the decoding of the AVISynth output. The best of both worlds, faster encoding with no quality loss (since the encoding is still done on one thread and isn't "sliced"), however the speed increase is not as large as you would get with --threads. You might be able to free up 30% extra speed or so. ***--no-asm [#y1217de9] Usage: --no-asm No ASM disables all CPU optimisations. This makes things very slow, and is not required for general use, just debugging and/or troubleshooting. ***--no-psnr [#u54e1dc8] Usage: --no-psnr No PSNR disables the PSNR computation that is displayed after an encode. It does not affect quality and disabling it brings a little speed increase. Unless you want it enabled it would be good to use --no-psnr. ***--quiet [#w6747e0d] Usage: --quiet Quiet supresses output to the console from the encoder. ***--verbose [#b1fc28ef] Usage: --verbose Verbose prints the stats for each frame and is generally slower and not required. It is recommended to leave this turned off. ***--progress [#i8d80a03] Usage: --progress Shows a progress indicator while encoding. This is pretty much essential and shows you the ETA, frames encoded, frames left and frames per second being encoded. ***--visualize [#e604093e] Usage: --visualize Visualise shows you the macroblocks and motion vectors over the encoded video. Currently x264 is not compiled with this, but it will be slow and next to useless for most people. This is best left off. ***--aud [#r6621374] Usage: --aud Uses Access Unit Delimiters. It is used to mark frame start points, for streaming and storage in MPEG-2 Transport streams (.ts). They also seem to be used in official H.264 encodes for Sony's PSP. Aside from using --aud for the PSP (which probably works fine without it), there isn't much reason since .ts as intended for DVB (Digital TV) transmissions, which usually contains multiple audio and video channels.
