AutoXvid.exe info here and your thoughts please?

[carpeVideo]

options part 2

frame_drop_ratio=<0−100> (max_bframes=0 only)
This setting allows the creation of variable framerate video streams. The value of the setting specifies a threshold under which, if the difference of the following frame to the previous frame is below or equal to this threshold, a frame gets not coded (a so called n-vop is placed in the stream). On playback, when reaching an n-vop the previous frame will be displayed.
WARNING: Playing with this setting may result in a jerky video, so use it at your own risks!
rc_reaction_delay_factor=<value>
This parameter controls the number of frames the CBR rate controller will wait before reacting to bitrate changes and compensating for them to obtain a constant bitrate over an averaging range of frames.
rc_averaging_period=<value>
Real CBR is hard to achieve. Depending on the video material, bitrate can be variable, and hard to predict. Therefore Xvid uses an averaging period for which it guarantees a given amount of bits (minus a small variation). This settings expresses the "number of frames" for which Xvid averages bitrate and tries to achieve CBR.
rc_buffer=<value>
size of the rate control buffer
curve_compression_high=<0−100>
This setting allows Xvid to take a certain percentage of bits away from high bitrate scenes and give them back to the bit reservoir. You could also use this if you have a clip with so many bits allocated to high-bitrate scenes that the low(er)-bitrate scenes start to look bad (default: 0).
curve_compression_low=<0−100>
This setting allows Xvid to give a certain percentage of extra bits to the low bitrate scenes, taking a few bits from the entire clip. This might come in handy if you have a few low-bitrate scenes that are still blocky (default: 0).
overflow_control_strength=<0−100>
During pass one of two pass encoding, a scaled bitrate curve is computed. The difference between that expected curve and the result obtained during encoding is called overflow. Obviously, the two pass rate controller tries to compensate for that overflow, distributing it over the next frames. This setting controls how much of the overflow is distributed every time there is a new frame. Low values allow lazy overflow control, big rate bursts are compensated for more slowly (could lead to lack of precision for small clips). Higher values will make changes in bit redistribution more abrupt, possibly too abrupt if you set it too high, creating artifacts (default: 5).
NOTE: This setting impacts quality a lot, play with it carefully!
max_overflow_improvement=<0−100>
During the frame bit allocation, overflow control may increase the frame size. This parameter specifies the maximum percentage by which the overflow control is allowed to increase the frame size, compared to the ideal curve allocation (default: 5).
max_overflow_degradation=<0−100>
During the frame bit allocation, overflow control may decrease the frame size. This parameter specifies the maximum percentage by which the overflow control is allowed to decrease the frame size, compared to the ideal curve allocation (default: 5).
container_frame_overhead=<0...>
Specifies a frame average overhead per frame, in bytes. Most of the time users express their target bitrate for video w/o taking care of the video container overhead. This small but (mostly) constant overhead can cause the target file size to be exceeded. Xvid allows users to set the amount of overhead per frame the container generates (give only an average per frame). 0 has a special meaning, it lets Xvid use its own default values (default: 24 − AVI average overhead).
profile=<profile_name>
Restricts options and VBV (peak bitrate over a short period) according to the Simple, Advanced Simple and DivX profiles. The resulting videos should be playable on standalone players adhering to these profile specifications.
unrestricted
no restrictions (default)
sp0
simple profile at level 0
sp1
simple profile at level 1
sp2
simple profile at level 2
sp3
simple profile at level 3
asp0
advanced simple profile at level 0
asp1
advanced simple profile at level 1
asp2
advanced simple profile at level 2
asp3
advanced simple profile at level 3
asp4
advanced simple profile at level 4
asp5
advanced simple profile at level 5
dxnhandheld
DXN handheld profile
dxnportntsc
DXN portable NTSC profile
dxnportpal
DXN portable PAL profile
dxnhtntsc
DXN home theater NTSC profile
dxnhtpal
DXN home theater PAL profile
dxnhdtv
DXN HDTV profile
NOTE: These profiles should be used in conjunction with an appropriate −ffourcc. Generally DX50 is applicable, as some players do not recognize Xvid but most recognize DivX.

par=<mode>
Specifies the Pixel Aspect Ratio mode (not to be confused with DAR, the Display Aspect Ratio). PAR is the ratio of the width and height of a single pixel. So both are related like this: DAR = PAR * (width/height).
MPEG-4 defines 5 pixel aspect ratios and one extended one, giving the opportunity to specify a specific pixel aspect ratio. 5 standard modes can be specified:
vga11
It is the usual PAR for PC content. Pixels are a square unit.
pal43
PAL standard 4:3 PAR. Pixels are rectangles.
pal169
same as above
ntsc43
same as above
ntsc169
same as above (Do not forget to give the exact ratio.)
ext
Allows you to specify your own pixel aspect ratio with par_width and par_height.
NOTE: In general, setting aspect and autoaspect options is enough.
par_width=<1−255> (par=ext only)
Specifies the width of the custom pixel aspect ratio.
par_height=<1−255> (par=ext only)
Specifies the height of the custom pixel aspect ratio.
aspect=<x/y | f (float value)>
Store movie aspect internally, just like MPEG files. Much nicer solution than rescaling, because quality is not decreased. MPlayer and a few others players will play these files correctly, others will display them with the wrong aspect. The aspect parameter can be given as a ratio or a floating point number.
(no)autoaspect
Same as the aspect option, but automatically computes aspect, taking into account all the adjustments (crop/expand/scale/ etc.) made in the filter chain.
psnr
Print the PSNR (peak signal to noise ratio) for the whole video after encoding and store the per frame PSNR in a file with a name like ’psnr_hhmmss.log’ in the current directory. Returned values are in dB (decibel), the higher the better.
debug
Save per-frame statistics in ./xvid.dbg. (This is not the two pass control file.)
The following option is only available in Xvid 1.1.x.
bvhq=<0|1>
This setting allows vector candidates for B-frames to be used for the encoding chosen using a rate distortion optimized operator, which is what is done for P-frames by the vhq option. This produces nicer-looking B-frames while incurring almost no performance penalty (default: 1).
The following option is only available in the 1.2.x version of Xvid.
threads=<0−n>
Create n threads to run the motion estimation (default: 0). The maximum number of threads that can be used is the picture height divided by 16.

[tvshowman]

Great post. Very appreciated.

I tried your new batch file and got this error

Code:

C:\1>mencoder -sws 9 -lavdopts threads=1 -ovc xvid -xvidencopts bitrate=1024:me_
quality=4:chroma_me:noqpel:chroma_ opt:vhq=4:bvhq=1:trellis:hq_ac:quant_type=mpe
g:tur bo:threads=2pass=1 -oac mp3lame -af volnorm -lameopts mode=2:cbr:br=128 -v
f decimate=2:1000:1600:.001, -fps 60000/1001 -ofps 24000/1001 -o test.avi
MEncoder dev-SVN-r25953-4.2.3 (C) 2000-2008 MPlayer Team
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (Family: 15, Model: 4, Stepping: 3)
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

Option xvidencopts: Unknown suboption chroma_
Error parsing option on the command line: -xvidencopts

Exiting... (error parsing command line)

Option xvidencopts: Unknown suboption chroma_
Error parsing option on the command line: -xvidencopts

Exiting... (error parsing command line)

Any idea what should be changed?

Cheers

[carpeVideo]

Yes - it looks like there is a space between "chroma_ opt" there should not be a space. I really meant that as a starting point since I don't know how good the file it generates is. Looks like there are several other errant spaces as well "tur bo". Looking at it again it looks like the first pass of a two pass.

As I mentioned if you grab stattiks batch file you can drag and drop a file with no spaces in the name it should give you options to do all of these automatically. Or if f you use it in a command window you can see the whole mencoder line he generates for any of the options and cut and paste those for more experimentation. I recommend that since they are all tested.

I also have a simpler batch file at home that has 3 compression options which I can post later - basically I compress HD files to about a 3rd of their size with great quality. I don't need much more since I rarely keep the files around for more than a month.

CV

[tvshowman]

hey that is a cool string.
I got it to work and it is processing a file at 63fps.

have to wait for the quality but speed is killer

here is the string

Code:

mencoder %1 -sws 9 -lavdopts threads=1 -ovc xvid -xvidencopts bitrate=1024:me_quality=4:chroma_me:noqpel:chroma_opt:vhq=4:bvhq=1:trellis:hq_ac:quant_type=mpeg:turbo:threads=2:pass=1 -oac mp3lame -af volnorm -lameopts mode=2:cbr:br=128 -vf decimate=2:1000:1600:.001, -fps 60000/1001 -ofps 24000/1001 -o test.avi

I can't figure out how to make it the string to work in a batch file so I can drop an mpg on to it and it will process and rename the file to avi...
any ideas?

cheers!

[carpeVideo]

Edit this batch file to have the correct paths to gbpvr , mencoder and ffdshow then drag and drop on to it.

[leecole]

"I currently cannot do any and files are placed in root and nothing deleted and i'm really lost."
AutoXvid has AutoGK build the AVI (DivX or Xvid) in the root directory, because BeyondTV, the program it was originally written for, dynamiclly updates (modifies) all video files that are in it's folders. So to prevent BTV and AutoGK from both writing to the same file at the same time, I have AutoGK use the root directory as it's work area. A program named ScheduledRun.exe should have been running in the system tray, monitoring AutoGK's progress. Once AutoGK completes the avi, it creates a "recording name"_agk.log. This should alert ScheculedRun that this job is finished. ScheduledRun should then move the AVI to it's destination and done cheanup.
I don't currently use GBPVR, but the last time I was able to test against GBPVR, it was working.
If you don't mind my getting your email address, you can email me at leecole@bigfoot.com with AutoXvid keyword in the subject line.
Send me a copy of your AutoXvid.ini and a log of when the problem occured.
Set
[AutoXvid]
Logging= Yes
and a file named AutoXvid.log will be created as a recording is processed. After you reboot, the log is archived in the \log sebdirectory.
Lee

[tvshowman]

thanks lee I sent you an email.

I had a huge hard drive crash on one of my fast computers I used to convert files. The file system got corrupt and windows had an unmountable boot volume error which was fixed after running chkdsk /r for 12 hours....

does anyone know if encoding files can strain the hard like recording would do?

this was not a GBPVR computer.

cheers!

[wtg]

Recordings don't really strain the hard drive. I can have 3 or 4 recordings going at one, 2 HD, and the hard drive keeps up. A heavily fragmented drive can have issues, giving the OS a work-out to keep track of the fragments and jumping the head all over locating them, and it does increase the chances that a poorly timed power failure could corrupt the file system.

However, in general recording isn't a strain on the system.