ageha was here

--output
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

--sar
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:

（表略）

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.

原文のSAR表は以下の情報と矛盾します。
横幅720と704では、同じSAR値を使うべきケースが存在するようです。

アスペクト比 part3 http://pc11.2ch.net/test/read.cgi/avi/1174473555/-100

---

32 ：孫極右：2007/03/23(金) 22:00:24
>>26
720x480(無効領域なし)の16:9 - 32:27
720x480(無効領域あり)の16:9 - 40:33
704x480(無効領域Crop)の16:9 - 40:33

720x480(無効領域なし)の4:3 - 8:9
720x480(無効領域あり)の4:3 - 10:11
704x480(無効領域Crop)の4:3 - 10:11

例　DAR(Display Aspect Ratio)を4:3、画素数が720*480の場合、
　　par_x = DAR_x * hight = 4 * 480 = 1920
　　par_y = DAR_y * width = 3 * 720 = 2160
　　1920:2160→8:9

　　(4 * 480):(3 * 352)=20:11

　これは以下２点とも整合します。

1. ガーベラ　趣味の花束ブログ: x264 CLI アスペクト比　SARについて（2005年10月23日）
2. Wikipedia：アスペクト比
1. 720×480 (NTSCのデジタルSDTV、DVDなど)、704×480、352×240 (ビデオCDなど) のピクセルは、10:11。
2. 1920×1080（デジタルHDTV）、ワイド720×480（DVDのスクイズ収録）のピクセルは、40:33。

　引用文中の式では横幅720と704で数字が変わりますが、無効領域（乱暴に言うとブラウン管用のマージン）の扱いに注意が必要と思われます。無効領域の有無の見分け方は不詳。

　原文の表は下記に従ったものと思われます。

＊x264のsvnソースコード内/doc/vui.txtより

 SAR_x DAR_x * height
 ----- = --------------
 SAR_y DAR_y * width
 
 for example:
 width x height = 704x576, DAR = 4:3 ==> SAR = 2304:2112 or 12:11

　これに従う限り、横幅 720と704ではSARを変える必要があるのですが、これに続いて "素材がデジタル化されたアナログ信号の場合はこの式を使うな"。とも書いてあります。

 Please note that if your material is a digitized analog signal, you should
 not use this equation to calculate the SAR. Refer to the manual of your
 digitizing equipment or this link instead.

 A Quick Guide to Digital Video Resolution and Aspect Ratio Conversions
 http://www.iki.fi/znark/video/conversion/

　このリンク先を読むとどうやらかなり広汎な、むしろ現在身の回りにあるほとんどの素材がこれに該当するようです。

--fps
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
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
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.

--level
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.

http://aflux.deltaanime.net/Zero1/MP4/x264_files/h264levels.png

--verbose
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
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.

--no-psnr
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.

--threads
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
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
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.

--visualize
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
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.