Introduction

Based on mplayers DOCS/tech/libavc-option.txt

Modified for transcode.

Some (basic) options are supported through the transcode commandline and some through ffmpeg.cfg or ~/.ffmpeg.cfg. The format of ffmpeg.cfg is simple. It can consists of several sections, each prefix by a header [codec] which is the same string you give to transcode through -F. To see all available options, have a look at
either export/ffmpeg_cfg.c:90ff or run transcode -y ffmpeg -F mpeg4 -q2

WARNING: I am no encoding expert so the recommendations might be bad ... if you find any errors, missing stuff, ... send a patch or cvs commit if you have an cvs account :)

Encoder options (lavcopts)

vqmin 1-31 (minimum quantizer) for pass1/2

1 is not recommended (much larger file, little quality difference (if u are lucky)
and other weird things (if u are less lucky))
weird things: msmpeg4, h263 will be very low quality
ratecontrol will be confused -> lower quality
some decoders will not be able to decode it
2 is recommended for normal mpeg4/mpeg1video encoding (default)
3 is recommended for h263(p)/msmpeg4
the reason for 3 instead of 2 is that 2 could lead to overflows
(this will be fixed for h263(p) by changing the quanizer per MB in
the future, but msmpeg4 doesnt support that so it cant be fixed for
that)

keyframes are needed for seeking as seeking is only possible to a
keyframe but they need more space than non-keyframes so larger numbers here
mean slightly smaller files, but less precise seeking
0 no keyframes
>300 is not recommended as the quality might be bad (depends upon
decoder, encoder and luck)
for strict mpeg1/2/4 compliance this would have to be <=132

TRANSCODE: use -w X,X,keyint

vb_strategy 0-1 for pass 2

0 allways use the max number of B frames (default)
1 avoid B frames in high motion scenes (this will cause bitrate
misprediction)

vpass

1 first pass
2 second pass
(only need to specify if two-pass encoding is used)
Tip: u can try to use constant quantizer mode for pass1 (vqscale=<quantizer>)
for huffyuv:
pass 1 saves statistics
pass 2 encodes with a optimal huffman table based upon the pass 1 stats

TRANSCODE: use -R (1|2)

vbitrate (kbits per second) for pass1/2

800 is default
(if value is bigger then 16000 it is interpreted as bit not kbit!)

TRANSCODE: use -w bitrate

vratetol (filesize tolerance in kbit) for pass1/2

this is just an approximation, the real difference can be much smaller
or larger
1000-100000 is a sane range
8000 is default

vrc_maxrate (maximum bitrate in kbit/sec) for pass1/2

vrc_minrate (minimum bitrate in kbit/sec) for pass1/2

vrc_buf_size (buffer size in kbit) for pass1/2

this is for stuff like VCD
VCD: FIXME
SVCD: ...
DVD: 1792
Note: vratetol should not be too large during the 2.pass or there might
be problems if vrc_(min|max)rate is used

0.0 qblur disabled
0.5 is the default
1.0 average the quantizer over all previous frames
larger values will average the quantizer more over time so that it will
be changed slower

vqblur (0.0-99.0) quantizer blur (pass2)

gaussian blur (gaussian blur cant be done during pass 1 as the future quantizers arent known)
0.5 is the default
larger values will average the quantizer more over time so that it will
be changed slower

vqcomp quantizer compression (for pass1/2)

depends upon vrc_eq

vrc_eq the main ratecontrol equation (for pass1/2)

1 constant bitrate
tex constant quality
1+(tex/avgTex-1)*qComp approximately the equation of the old ratecontrol code
tex^qComp with qcomp 0.5 or something like that (default)

0 disabled (default)
7 (JVT recommendation)
negative values will allso consider the dc coefficient
should be at least -4 or lower for encoding at quant=1

vstrict (-1,0,1) strict standard compliance

0 (default)
1 only recommended if you want to feed the output into the mpeg4 reference
decoder
-1 allows nonstandard YV12 huffyuv encoding (20% smaller files, but
cant be played back by the official huffyuv codec)

vdpart data partitioning

adds 2 byte per video packet
each videopacket will be encoded in 3 seperate partitions:
1. MVs (=movement)
2. DC coefficients (=low res picture)
3. AC coefficients (=details)
the MV & DC are most important, loosing them looks far worse than
loosing the AC and the 1. & 2. partition (MV&DC) are far smaller than
the 3. partition (AC) -> errors will hit the AC partition much more
often than the MV&DC -> the picture will look better with partitioning
than without, as without partitining an error will trash AC/DC/MV
equally
improves error-resistance when transfering over unreliable channels (eg.
streaming over the internet)

In signal processing lingo, decimate is generally
understood to mean filter and decimate to remove
high frequency components that are not part of the
signal. This is what the nr option does (I think).
Using values between 10-250 (this is the range I
have tested) seem to be effective, with 20 as a
good choice for a default for high quality source,
and 120 as a good default for "average" quality
source. The effect is similar to that of a good
denoiser, but with very little overhead.
It is a mystery to me why the scale for this option
extends over 5 orders of magnitude.
nr should ONLY EVER BE USED IN 2-PASS MODE!! In
single-pass it is unpredictable and always BAD.

0.0 disabled (default)
0.0-0.3 should be a sane range
warning: be carefull, too large values can cause disasterous things
warning2: large values might look good on some monitors but may look horrible
on other monitors

dark_mask (0.0-1.0) darkness masking

0.0 disabled (default)
0.0-0.3 should be a sane range
warning: be carefull, too large values can cause disasterous things
warning2: large values might look good on some monitors but may look horrible
on other monitors / TV / TFT

tcplx_mask (0.0-1.0) temporal complexity masking

0.0 disabled (default)

scplx_mask (0.0-1.0) spatial complexity masking

0.0 disabled (default)
0.0-0.5 should be a sane range
larger values help against blockiness, if no deblocking filter is used
for decoding
Tip: crop any black borders completly away as they will reduce the quality
of the MBs there, this is true if scplx_mask isnt used at all too

naq normalize adaptive quantization (experimental)

when using adaptive quantization (*_mask), the average per-MB quantizer
may no longer match the requested frame-level quantizer. using naq will
attempt to adjust the per-MB quantizers to maintain the proper average.

this will find the optimal encoding for each 8x8 block
trellis quantization is quite simple a optimal quantization in the
PSNR vs bitrate sense (assuming that there would be no rounding errors introduced
by the IDCT, which is obviously not the case) it simply finds a block for the minimum of
error + lambda*bits
lambda is a qp dependant constant
bits is the amount of bits needed to encode the block
error is simple the sum of squared errors of the quantization

last_pred (0-99) amount of motion predictors from the previous frame

0 (default)
a -> will use 2a+1 x 2a+1 MB square of MV predictors from the previous frame

preme (0-2) Motion estimation pre-pass

0 disabled
1 only after I frames (default)
2 allways

subq (1-8) subpel refinement quality (for qpel)

8 (default)
Note: this has a significant effect on the speed

psnr will print the psnr for the whole video after encoding and store the per frame psnr

in a file with name like "psnr_012345.log"

fps_code (1-8) will flag the framerate headers with the new framerate code