1# ############################################################################ 2# XviD 1.0 configuration file for transcode 3# ############################################################################ 4 5 6# ---------------------------------------------------------------------------- 7# 8# Section: Features 9# 10# The fist section of this configuration file concerns what is labeled as 11# "features". This allows you to turn on/off some options to adapt XviD to 12# your needs. 13# ---------------------------------------------------------------------------- 14 15[features] 16 17# MPEG4 allows two methods to compress the image, the first one is derived 18# from h263, the other one is inspired by the MPEG2 matrix quantization. 19# 20# NB: defaults to h263 if a typing mistake is done. 21# defaults to mpeg if custom matrices filenames are specified. 22# 23# Values = h263 | mpeg 24 25quant_type = h263 26 27 28# This option controls the motion estimation subsystem. The higher the value, 29# the more precise the estimation should be. The more precise the motion 30# estimation is, the more bits can be saved. Precision is gained at the 31# expense of CPU time so decrease this setting if you need realtime encoding. 32# 33# Values = [0..6] 34# 35# 0 None 36# 1 Very Low 37# 2 Low 38# 3 Medium 39# 4 High 40# 5 Very High 41# 6 Ultra High 42# 43# Default = 6 44 45motion = 6 46 47# Motion estimation involves lot of refinement steps. Usually these steps help 48# reaching better quality, but not by much, and they use a fair amount of CPU. 49# So if you want to speedup Motion Estimation by skipping some refinement steps 50# and using simplified ME functions, you can activate the turbo mode. 51# 52# This setting turns on the ME turbo mode. 53# 54# Values = 0 (no) | 1 (yes) 55# Default = 0 56 57turbo = 0 58 59# The usual motion estimation algorithm uses only the luminance information 60# to find the best motion vector. However for some video material, using 61# the chromatic planes can help find better vectors. 62# 63# This setting turns on/off the use of chroma planes for Motion Estimation 64# 65# Values = 0 (no) | 1 (yes) 66# Default = 1 67 68chromame = 1 69 70 71# The motion search algorithm is based on a search in the usual color domain 72# and tries to find a motion vector that minimizes the difference between 73# the reference frame and the encoded frame. 74# 75# Activating this setting, XviD will also use the frequency domain (DCT) to 76# search a motion vector that minimizes not only the spatial difference but 77# also the encoding length of the block. The higher, the more precise and more 78# CPU intensive 79# 80# Values = [0..4] 81# 82# 0 Disabled 83# 1 Mode decision 84# 2 Limited search 85# 3 Medium search 86# 4 Wide search 87# 88# Default = 1 89 90vhq = 1 91 92 93# BFrames are the third type of frames available in MPEG4, they are predicted 94# thanks to 2 reference frames. Thus, bframes help usually in two cases: 95# 1/ saving bitrate w/o loss of quality 96# 2/ increasing the quality for a same bitrate 97# 98# This setting controls how many bframes the xvid encoder can output in a row. 99# 100# You must be aware that the higher max_bframes is, the more distant reference 101# frames are from each other. Thus prediction of reference frames become hard 102# and results in poor quality. If the reference frames have poor quality, so 103# the bframes will have. So as a rule of thumb, this setting has to be tuned 104# according to your exact needs. CVommon values are [0..2] for "natural movies 105# and a bit higher values for anime/cartoons with great amounts of constant color 106# areas. 107# 108# Values = >=0 (0 disables bframes usage) 109# Default = 1 110 111max_bframes = 1 112 113 114# As explained before, BFrames are highly correlated to its reference frames 115# Thus XviD computes their quantizer to its reference's quantizers. 116# 117# This two settings allow you to tune the formula: 118# 119# Values = [0..200] 120# Default = ratio 150 & offset 100 121 122bquant_ratio = 150 123bquant_offset = 100 124 125 126# Sometimes BFrames do not look good, and introduce artefacts when most of the 127# frame is static and some small zones have high motion (a static scene with a 128# man talking, his mouth will probably look bad if what is surrounding the man 129# and his mouth is completly static) 130# 131# This setting allow you to favorize or not, the use of bframes. The higher the 132# value, the more a bframe has chance to be used. 133# 134# Values [-255..255] 135# Default = 0 136 137bframe_threshold = 0 138 139 140# MPEG4 uses a half pixel precision for its motion search by default. The 141# standard proposes a mode where encoders are allowed to use quarter pixel 142# precision. 143# 144# This option usually results in sharper image. But it has great impact on 145# bitrate and sometimes the higher use of bitrate will prevent it from giving 146# a better image quality at a fixed bitrate. The better is to test w and w/o it 147# and choose after this test, if it's worth activting it. 148# 149# Values = 0 (no) | 1 (yes) 150# Default = 0 151 152quarterpel = 0 153 154 155# Makes XviD generates Sprite Frame which describe best Pan/Zoom/Rotating 156# images. Deciding wether or not you must activate it depends highly on the 157# video material 158# 159# Values = 0 (no) | 1 (yes) 160# Default = 0 161 162gmc = 0 163 164 165# Trellis Quantization is a kind of adaptive quantization method that saves 166# bits modifying quantized coefficients to make them more compressable by the 167# entropy encoder. 168# 169# Its impact on quality is good, and if VHQ uses too much CPU for you, this 170# setting can be a good alternative to save a few bits (and gain quality at 171# fixed bitrate) at a minimum expense. 172# than VHQ 173# 174# Values = 0 (no) | 1 (yes) 175# Default = 0 176 177trellis = 0 178 179 180# Depending on the container and frontend API, sometimes it is good to ask XviD 181# to group the first bframe of a group with its forward reference frame, that 182# prevents A/V desync 183# 184# This setting would be useful if it was used with VFW 1.1 encoders (Windows) 185# because this API does not allow audio contention when no video frames are 186# output. 187# 188# But transcode does not suffer from that API problem and the xvid4 module 189# informs transcode to delay frames when needed, so this option is mostly not 190# needed with transcode. 191# 192# Values = 0 (no) | 1 (yes) 193# Default = 0 194 195packed = 0 196 197 198# A GOP is a Group Of Pictures. Its bounded by two Intra Frames. 199# 200# This option controls if XviD must close a GOP, which means that a GOP is 201# independent from the next GOP. This implies just that the last frame of 202# the GOP is eiter a PFrame or a SFrame but not a BFrame. This is usually 203# a good idea to turn on the option 204# 205# Values = 0 (no) | 1 (yes) 206# Default = 1 207 208closed_gop = 1 209 210 211# For interlaced video material, turn this option to on. 212# 213# Values = 0 (no) | 1 (yes) 214# Default = 0 215 216interlaced = 0 217 218 219# Activate this if your encoded sequence is an Anime/Cartoon. It modifies some 220# XviD internal thresholds so XviD takes better decisions on frame types and 221# motion vectors for flat looking cartoons. 222# 223# Values = 0 (no) | 1 (yes) 224# Default = 0 225 226cartoon = 0 227 228 229# Activates High Quality AC coefficient prediction from neighboor blocks. 230# 231# Values = 0 (no) | 1 (yes) 232# Default = 1 233 234hqacpred = 1 235 236 237# XviD keeps track of block coding type (skipped, predicted, intra). The skipped 238# block counter can be used to choose wether a frame is so close to its reference 239# that it can be _completly_ skipped. 240# 241# This setting allows you to choose the (100 - value) threshold for skipping a 242# frame. 243# 244# Values = [0..100] (0 -> never skip a frame, 100 -> skip all frames) 245# Default = 0 246 247frame_drop_ratio = 0 248 249# XviD discard chroma planes bitstream so the encoded video is greyscale only. 250# Note that this does not speed up encoding, that just prevent chroma data 251# from being written in the last stage of encoding. 252# 253# This setting enable Chroma color discarding. 254# 255# Values = 0 (no) | 1 (yes) 256# Default = 0 257 258greyscale = 0 259 260# For testing purposes, or quality measurement, XviD can return some stats 261# about the encoded frames. 262# 263# This option activates PSNR measurement, the average PSNR is displayed at the 264# end of the encoding session. This option is probably something a Joe user 265# does not really care. This option makes the encoding a bit slower. 266# 267# Values = 0 (no) | 1 (yes) 268# Default = 0 269 270stats = 0 271 272# When doing the first pass of a 2-pass encode, the encoder takes some 273# shortcuts and does not produce a full quality encode. Must users have 274# no reason to do this, since the first pass is usually discarded. 275# 276# Setting this option forces the encoder to produce a full quality first 277# pass at Q2. Enabling this makes the first pass a lot slower, and should 278# only be enabled if you're using the resuts of the first pass for something. 279# 280# Values = 0 (standard first pass) | 1 (full quality first pass) 281# Default = 0 282 283full1pass = 0 284 285# ---------------------------------------------------------------------------- 286# 287# Section: Quantizer 288# 289# This section allows you to tune quantizing process. 290# ---------------------------------------------------------------------------- 291 292[quantizer] 293 294# The next 6 settings control the valid range of quantizers for a specific frame 295# type 296# 297# a [2..31] range is probably good for all sequences, you can decrease the higher 298# bound limit if you notice some scenes with artefacts. However, restricting the 299# valid range can make the bitrate controller fails to achieve the desired bitrate 300# 301# Use this ranges with MUCH care 302# 303# Values = [0..31] 304# 1-> small quantizer -> better quality 305# 31-> high quantizer -> bad quality 306# 0 has a special meaning, it lets XviD uses its own default values 307 308min_iquant = 2 309max_iquant = 31 310min_pquant = 2 311max_pquant = 31 312min_bquant = 2 313max_bquant = 31 314 315# With the MPEG quantization method you can provide custom matrices optimized 316# your video material. 317# 318# A matrix file is just a file where 64 decimal values ranged in 1..255 are 319# specified separated by space chars (newline, space, tabs) 320# 321# The 8x8 matrix is then rebuilt like that 322# 323# [ first coeff, second coeff, ... eighth coeff] 324# [ ninth coeff, ... ] 325# [ ... ] 326# [ ] 327# [ ] 328# [ ] 329# [ ] 330# [ ] 331# 332# Value = filename of the matrix 333# Default : none (no custom matrix) 334 335#quant_intra_matrix = 336#quant_inter_matrix = 337 338 339# ---------------------------------------------------------------------------- 340# 341# Section: CBR 342# 343# This section allows you to tune the Constant Bitrate settings. 344# ---------------------------------------------------------------------------- 345 346[cbr] 347 348# This parameter controls the delay in frames before the CBR rate controller 349# will react to bitrate changes and will try to compensate the change to obtain 350# a constant bitrate over an averaging range of frames (see below). 351# 352# Value = >=0 353# Default = 16 354# 0 has a special meaning, it lets XviD uses its own default values 355 356reaction_delay_factor = 16 357 358 359# Real CBR is hard to achieve. Depending on the video material, bitrate can be 360# variable, and hard to predict. That's why XviD uses an averaging period for 361# which it guarantees a given amount of bits (minus a small variation). 362# 363# This settings express the "number of frames" for which XviD averages bitrate 364# and tries to achieve CBR. 365# 366# Value = >=0 367# Default = 100 368# 0 has a special meaning, it lets XviD uses its own default values 369 370averaging_period = 100 371 372 373# Todo: find its exact meaning 374# 375# Value = >=0 376# Default = 100 377# 0 has a special meaning, it lets XviD uses its own default values 378 379buffer = 100 380 381# ---------------------------------------------------------------------------- 382# 383# Section: VBR 384# 385# This section allows you to tune the Variable Bitrate controller settings. 386# (2nd pass control in simpler words) 387# ---------------------------------------------------------------------------- 388 389[vbr] 390 391# The two pass algorithm scales the initial bitrate curve to obtain one that 392# respect both the user target bitrate and the natural shape of the first pass 393# curve. However it is possible to give an additionnal amount of bits for Intra 394# frames. 395# 396# This setting tells how many additional amount of bits, Intra Frames are 397# supposed to be given (this "bossting" amount of bits is compensated by 398# subtracting the same amount of bits from other frame types pool) 399# 400# Value = [0..100] 401# Default = 0 402 403keyframe_boost = 0 404 405 406# This settigs control how much the upper part of the curve has to get closer 407# to the average bitrate value. The upper part of the curve is the set of values 408# that are higher than the curve average. It is expressed in %. 409# 410# Think of that setting like a shrinking factor for the upper part of the 411# curve. 412# 413# Value = [0..100] 414# Default = 0 415 416curve_compression_high = 0 417 418 419# This settigs control how much the lower part of the curve has to get closer 420# to the average bitrate value. The lower part of the curve is the set of values 421# that are lower than the curve average. It is expressed in %. 422# 423# Think of that setting like a growing factor for the lower part of the 424# curve. 425# 426# Value = [0..100] 427# Default = 0 428 429curve_compression_low = 0 430 431 432# During two pass, a scaled bitrate curve is computed. The difference between 433# that expected curve and the result obtained during encoding is called 434# overflow. Obviously, the two pass Rate Controller tries to compensate 435# that overflow distributing it over next frames to be encoded. 436# 437# This setting controls how much overflow is distributed at each new frame. 438# Low values allow lazy overflow control, big rate bursts are compensated more 439# slowly (could lead to lack of precision for small clips). High values 440# make RC compensate very hard the overflow, this can have a very bad impact on 441# quality during rate bursts. 442# 443# NB: This setting impacts quality a lot, play with it carefully ! 444# 445# Value = [0..100] 446# Default = 0 447# 0 has a special meaning, it lets XviD uses its own default values 448 449overflow_control_strength = 5 450 451# During the frame bit allocation, overflow control may increase the frame 452# size. This parameter controls how much the overflow control is allowed 453# to increase the frame size in percent compared to the ideal curve allocation 454# 455# Value = >=0 456# Default = 60 457# 0 has a special meaning, it lets XviD uses its own default values 458 459max_overflow_improvement = 5 460 461 462# During the frame bit allocation, overflow control may decrease the frame 463# size. This parameter controls how much the overflow control is allowed 464# to decrease the frame size in percent compared to the ideal curve allocation 465# 466# Value = >=0 467# Default = 60 468# 0 has a special meaning, it lets XviD uses its own default values 469 470max_overflow_degradation = 5 471 472 473# This reduction factor is the maximum allowed keyframe penalty applied to 474# a frame in a ivop sequence. The more the frame is distant from the last 475# ivop in the consecutive ivop sequence, the more penalty it is applied. 476# This ensures a maximum bitrate allocation to the last ivop, thus favorizing 477# a good reference frame for following p/s/b vops. 478# 479# Value = >=0 480# Default = 20 481# 0 has a special meaning, it lets XviD uses its own default values 482 483kfreduction = 20 484 485 486# Distance between two ivops so that it is not decresed its bit allocation by 487# the ivop reduction mechanism. 488# 489# Value = >=0 490# Default = 1 491# 0 has a special meaning, it lets XviD uses its own default values 492 493kfthreshold = 1 494 495 496# Most of the time users express their target bitrate for video w/o taking care 497# of the video container overhead. This small but (mostly) constant overhead 498# can make the target file size is not respected (oversized result). We decided 499# to allow users to set the amount of overhead per frame the container generates 500# (give only an average per frame) 501# 502# Value = >=0 503# Default = 24 (AVI frame average overhead per frame in bytes) 504# 0 has a special meaning, it lets XviD uses its own default values 505 506container_frame_overhead = 24 507 508############################################################################## 509# Do not modify this tag comment 510# arch-tag: bb7970c1-33fb-4c8c-8d1b-742ff2e53336 xvid config file 511