xvid_encraw - Patched with AviSynth input support

[weaver4]

I see that xvid-encraw has picked up a lot of momentum. So, I want to learn a little more about it. Are there any guides or manuals that I could look at.

[squid_80]

xvid_encraw -help and this thread from about page 11 onwards.

[elguaxo]

I am using the xvid_encraw version that comes with MeGUI. I don't remember when it was last updated, but the Greyscale (-grey) option is not available:

D:\megui\tools\xvid_encraw>xvid_encraw -help
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


xvid_encraw built at 17:33:35 on Apr 30 2006
Usage : xvid_encraw [OPTIONS]

Input options:
-i string : input filename (stdin)
-type integer: input data type (yuv=0, pgm=1, avi/avs=2)
-w integer: frame width ([1.2048])
-h integer: frame height ([1.2048])
-frames integer: number of frames to encode

Output options:
-dump : save decoder output
-save : save an Elementary Stream file per frame
-o string : save an Elementary Stream for the complete sequence
-avi string: save an AVI file for the complete sequence
-mkv string: save a MKV file for the complete sequence

BFrames options:
-max_bframes integer: max bframes (2)
-bquant_ratio integer: bframe quantizer ratio (150)
-bquant_offset integer: bframe quantizer offset (100)

Rate control options:
-framerate float : target framerate (25.0)
-bitrate [integer] : target bitrate in kbps (700)
-size integer : target size in kilobytes
-single : single pass mode (default)
-cq float : single pass constant quantizer
-pass1 [filename] : twopass mode (first pass)
-full1pass : perform full first pass
-pass2 [filename] : twopass mode (2nd pass)
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight
-max_key_interval integer : maximum keyframe interval (300)

Single Pass options:
-reaction integer : reaction delay factor (16)
-averaging integer : averaging period (100)
-smoother integer : smoothing buffer (100)

Second Pass options:
-kboost integer : I frame boost (10)
-kthresh integer : I frame reduction threshold (1)
-kreduction integer : I frame reduction amount (20)
-ostrength integer : overflow control strength (5)
-oimprove integer : max overflow improvement (5)
-odegrade integer : max overflow degradation (5)
-chigh integer : high bitrate scenes degradation (0)
-clow integer : low bitrate scenes improvement (0)
-overhead integer : container frame overhead (24)
-vbvsize integer : use vbv buffer size
-vbvmax integer : vbv max bitrate
-vbvpeak integer : vbv peak bitrate over 1 second

Other options
-noasm : do not use assembly optmized code
-turbo : use turbo presets for higher encoding speed
-quality integer : quality ([0..6]) (6)
-vhqmode integer : level of R-D optimizations ([0..4]) (1)
-bvhq : use R-D optimizations for B-frames
-qpel : use quarter pixel ME
-gmc : use global motion compensation
-qtype integer : quantization type (H263:0, MPEG4:1) (0)
-qmatrix filename : use custom MPEG4 quantization matrix
-interlaced [integer] : interlaced encoding (BFF:1, TFF:2) (1)
-nopacked : Disable packed mode
-noclosed_gop : Disable closed GOP mode
-lumimasking : use lumimasking algorithm
-stats : print stats about encoded frames
-debug : activates xvidcore internal debugging output
-vop_debug : print some info directly into encoded frames
-nochromame : Disable chroma motion estimation
-notrellis : Disable trellis quantization
-imin integer : Minimum I Quantizer (1..31) (2)
-imax integer : Maximum I quantizer (1..31) (31)
-bmin integer : Minimum B Quantizer (1..31) (2)
-bmax integer : Maximum B quantizer (1..31) (31)
-pmin integer : Minimum P Quantizer (1..31) (2)
-pmax integer : Maximum P quantizer (1..31) (31)
-drop integer : Frame Drop Ratio (0..100) (0)
-start integer : Starting frame number
-threads integer : Number of threads
-progress [integer] : Show progress updates every n frames (10)
-par integer[:integer] : Set Pixel Aspect Ratio.
1 = 1:1
2 = 12:11 (4:3 PAL)
3 = 10:11 (4:3 NTSC)
4 = 16:11 (16:9 PAL)
5 = 40:33 (16:9 NTSC)
other = custom (width:height)
-help : prints this help message

NB: You can define 64 zones repeating the -z[qw] option as needed.

I downloaded the latest version available here (http://members.optusnet.com.au/squid_80/), but it is not there either:

c:\temp>xvid_encraw -help
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


xvid_encraw built at 02:09:09 on Oct 5 2006
Usage : xvid_encraw [OPTIONS]

Input options:
-i string : input filename (stdin)
-type integer: input data type (yuv=0, pgm=1, avi/avs=2)
-w integer: frame width ([1.2048])
-h integer: frame height ([1.2048])
-frames integer: number of frames to encode

Output options:
-dump : save decoder output
-save : save an Elementary Stream file per frame
-o string : save an Elementary Stream for the complete sequence
-avi string: save an AVI file for the complete sequence
-mkv string: save a MKV file for the complete sequence

BFrames options:
-max_bframes integer: max bframes (2)
-bquant_ratio integer: bframe quantizer ratio (150)
-bquant_offset integer: bframe quantizer offset (100)

Rate control options:
-framerate float : target framerate (25.0)
-bitrate [integer] : target bitrate in kbps (700)
-size integer : target size in kilobytes
-single : single pass mode (default)
-cq float : single pass constant quantizer
-pass1 [filename] : twopass mode (first pass)
-full1pass : perform full first pass
-pass2 [filename] : twopass mode (2nd pass)
-zq starting_frame float : bitrate zone; quant
-zw starting_frame float : bitrate zone; weight
-max_key_interval integer : maximum keyframe interval (300)

Single Pass options:
-reaction integer : reaction delay factor (16)
-averaging integer : averaging period (100)
-smoother integer : smoothing buffer (100)

Second Pass options:
-kboost integer : I frame boost (10)
-kthresh integer : I frame reduction threshold (1)
-kreduction integer : I frame reduction amount (20)
-ostrength integer : overflow control strength (5)
-oimprove integer : max overflow improvement (5)
-odegrade integer : max overflow degradation (5)
-chigh integer : high bitrate scenes degradation (0)
-clow integer : low bitrate scenes improvement (0)
-overhead integer : container frame overhead (24)
-vbvsize integer : use vbv buffer size
-vbvmax integer : vbv max bitrate
-vbvpeak integer : vbv peak bitrate over 1 second

Other options
-noasm : do not use assembly optmized code
-turbo : use turbo presets for higher encoding speed
-quality integer : quality ([0..6]) (6)
-vhqmode integer : level of R-D optimizations ([0..4]) (1)
-bvhq : use R-D optimizations for B-frames
-qpel : use quarter pixel ME
-gmc : use global motion compensation
-qtype integer : quantization type (H263:0, MPEG4:1) (0)
-qmatrix filename : use custom MPEG4 quantization matrix
-interlaced [integer] : interlaced encoding (BFF:1, TFF:2) (1)
-nopacked : Disable packed mode
-noclosed_gop : Disable closed GOP mode
-lumimasking : use lumimasking algorithm
-stats : print stats about encoded frames
-debug : activates xvidcore internal debugging output
-vop_debug : print some info directly into encoded frames
-nochromame : Disable chroma motion estimation
-notrellis : Disable trellis quantization
-imin integer : Minimum I Quantizer (1..31) (2)
-imax integer : Maximum I quantizer (1..31) (31)
-bmin integer : Minimum B Quantizer (1..31) (2)
-bmax integer : Maximum B quantizer (1..31) (31)
-pmin integer : Minimum P Quantizer (1..31) (2)
-pmax integer : Maximum P quantizer (1..31) (31)
-drop integer : Frame Drop Ratio (0..100) (0)
-start integer : Starting frame number
-threads integer : Number of threads
-progress [integer] : Show progress updates every n frames (10)
-par integer[:integer] : Set Pixel Aspect Ratio.
1 = 1:1
2 = 12:11 (4:3 PAL)
3 = 10:11 (4:3 NTSC)
4 = 16:11 (16:9 PAL)
5 = 40:33 (16:9 NTSC)
other = custom (width:height)
-help : prints this help message

NB: You can define 64 zones repeating the -z[qw] option as needed.

Where can I find a version that includes the -grey option?

[buzzqw]

while i perfectly agree... i never seen too -grey... but i will prefer the greyscale from avisynth

BHH

[kurt]

greyscale is part of the zones and it's missing in MeGUI. What you can do is to use a custom commandline:

eg:
-zones 1,w,0.5,25O/359,w,1,O/161519,w,0.04,25OG
--> last zone starts with frame 161519, has chroma optimizer and greyscale enabled, bframe sensivity of 25 and a weight of 0.04...

here are the complete zones parameters:


Rate control:
Weight 2.01 => ,w,2.01
Quantizer 5.01 => ,q,5.01

Begin with keyframe => ,K
Greyscale encoding => ,G
Chroma optimizer enabled => ,O
Cartoon Mode => ,C
BVOP sensivity 45=> ,45

[elguaxo]

I am pretty sure it was there sometime. It is even an option in MeGUI's XviD Configurations.

Edit: Great! Thanks kurt!!!

[squid_80]

New build available (for the second time this week): http://members.optusnet.com.au/squid_80/xvid_encraw.zip

Changes include plugh's alternative 2 pass algorithm (thread (http://forum.doom9.org/showthread.php?t=118419)) and Kopernikus's HVS mods (thread (http://forum.doom9.org/showthread.php?t=114811)). Also some SSIM options from xvid's CVS.

[henryho_hk]

I am using Celtic Druid's 2006.12.08 CVS compile of XviDcore.dll on a Core 2 Duo E6300 1.86GHz. The encoding FPS reported by xvid_encraw seems incorrect. A single pass encode of a 2hr50m 29.9fps was reported to be encoding at 34fps; however, it took 4hr40m totally, way slower than the reported speed. Or have I misunderstood the encoding fps?

[MatMaul]

I am using Celtic Druid's 2006.12.08 CVS compile of XviDcore.dll on a Core 2 Duo E6300 1.86GHz. The encoding FPS reported by xvid_encraw seems incorrect. A single pass encode of a 2hr50m 29.9fps was reported to be encoding at 34fps; however, it took 4hr40m totally, way slower than the reported speed. Or have I misunderstood the encoding fps?
Do you have fft3dGPU in your avs script ?
because when I use it, wrong fps is reported by xvid_encraw and x264.

[henryho_hk]

Do you have fft3dGPU in your avs script?

I am just using mpeg2source(), colormatrix(), tdeint(), degrainmedian() and crop().

[squid_80]

Or have I misunderstood the encoding fps?
It's encoding fps; it only measures the time taken to encode frames. It doesn't take into account the time taken to get the input frames i.e. avisynth processing.

[henryho_hk]

I don't get it. Playing back the AVS in media player classic takes about 25% CPU load only. How can it contribute for 16fps lost in encoding speed?

[squid_80]

So it's a simple enough script that can playback in realtime without lagging? I'd assumed it was more complicated. If you really want to benchmark the avs script open it with virtualdub, set video processing mode to direct stream copy, leave video compression set to none and run a video analysis pass.
Another thing is to make sure the script is outputting yv12, if it's not then some vfw codec might be used for the conversion.

[henryho_hk]

It's a rather simple script. I can play it realtime at 25% CPU load and a direct stream copy of VirtualDubMod runs at about 50fps. VirtualDubMod says "YV12" and "ATI YVU12 4:2:0 Planar".


vf="test.d2v"
mpeg2source(vf)
colormatrix(d2v=vf)
tdeint(order=1,mtnmode=0)
crop(8,0,704,480)
removegrain(mode=5)


I am now testing "-threads 3" (#core + 1) and see if it helps.

[mixanobios]

i have experienced the same problem with henryho_hk. if you want i can search for my megui logs

[squid_80]

I'm in the middle of building a dual core machine (literally putting it together), when it's properly setup I will add threaded code for the input stage and fix the encoding timers (and hopefully remember once and for all to also fix the size variables so they don't wrap to negatives with large files).

[G_M_C]

Do you have fft3dGPU in your avs script ?
because when I use it, wrong fps is reported by xvid_encraw and x264.

Could you please report that in the FFT3DGPU thread please ?
http://forum.doom9.org/showthread.php?t=89941&page=28

You may have to add a script-example + a clip example to make ... reproduce the error.

I ask this because i use fft3dgpu very often, and making it bug-free is offcourse imporatnt enough for all of us that do too.

[MatMaul]

I don't think it's a bug of fft3dGPU but just the way fps is calculated in xvid_encraw.

[Brother John]

Hi, squid_80.

Everytime I look at "xvid_encraw -help" I stumble over the outdated zones options. Isn't it time to document the zones feature properly? To do this you should remove the obsolete -zq and -zw lines from "Rate control options" and replace the note at the very end with a more detailed explanation. I put together the following text. What do you think about it?


Zones options:
You can define up to 64 zones using the -zones option as described below.

-zones start,mode,value[,options][/start,mode,value[,options]]...

Parameters of a zones use the comma (,) as delimiter. Multiple zones are
separated by a slash (/). The end of each zone is defined by either the start
of the following zone or the last frame of the input file.

start : Start frame of the zone.
mode : weight zone = w, quantizer zone = q
value : Depending on mode either the zone's weight or quantizer.
options : Enables certain encoder features for the zone. Each feature is
represented by a single letter. An integer number stands for
b-frame sensitivity. To enable multiple features at the same time
combine the appropriate symbols without any delimiting characters.
K = Begin with keyframe
O = Enable chroma optimizer
G = Greyscale encoding
C = Cartoon mode
integer = B-Frame sensitivity

Example:
To create a first zone starting at frame 0 with weight 1.0, all options
enabled and b-frame sensitivity -5, and a second zone starting at frame 1000
with constant quant 4 and no options enabled you would use the -zones option
like this:

-zones 0,w,1.0,-5KOGC/1000,q,4

[squid_80]

The old options (-zq and -zw) are still useful so I'll leave them in, but I'll add a small description to be displayed with -help and your longer description can be displayed with "-help zones" or if an error is detected in the -zones parameters.

With regards to the fps bugs, I am seeing very irregular things happening with my dual core machine and I have a hunch that it's due to the main thread jumping between cores. I remember reading that separate cores don't always have their clocks synchronised exactly, hence if the start time is taken from one core and the finish time is taken from the other the result isn't valid. This may be BS but I'm not sure how else to explain the fact that I'm seeing frames pop out with negative encoding times.

[foxyshadis]

Maybe it's one of those things that only works right if you start windows with /usepmtimer. If you already have it, then... dunno. What do you use? GetSystemTickCount?

[Brother John]

I’ve been wondering for some time now about a specific function in encraw, but search didn’t turn up anything useful.

In Xvid VfW you can set 1-pass target quant in the main dialog and 1-pass constant quant via the zones window. However in Xvid_Encraw I only find -cq for constant quant. No target quant at all. Am I blind? Is target quant not supported in encraw? Or is the VfW GUI misleading?

Also (if it does exist), would it be fair to say that Xvid’s target quant is a similar function to x264’s constant rate factor? Very roughly speaking, maybe. Just to get the general idea.

[Kopernikus]

There is no equivalent to x264s crf in xvid, IIRC target quant is equivalent to constant quant. If the target is not a integer, the quants are distributed to achieve a average quant near the target.

[henryho_hk]

Is target quant not supported in encraw?

Both are supported: -cq and -zones

Xvid’s target quant is a similar function to x264’s constant rate factor?

I am afraid not. But you can take a look at the thread " Isn't it time for a new compression mode in XviD?".

[elfurbe]

So, it seems that no matter how many threads I specify, xvid_encraw never spawns more than one, at least according to task manager. I've got an A64 4400+ dual-core, so I used -threads 3 (cause I've found one more threads than cores is ideal for most tasks) but Task Manager shows it at 1 thread which is disturbing slow (5.6fps) on pass2 and pretty damn slow on pass1 (~20fps). The AVS framesize is 960x544, down-resing from 720p HDTV content.

What am I doing wrong? Here's my avs file and encode lines:

AVS:
LoadPlugin("c:\plugins\dgdecode.dll")
LoadPlugin("c:\plugins\TIVTC.dll")
mpeg2source("C:\file.d2v")
SelectEven()
Tdecimate()
LanczosResize(960,544,0,0,1280,720)
UnDot()

Pass 1:
xvid_encraw -bitrate 2300 -pass1 -threads 3 -progress -turbo -i file.avs -mkv file.mkv

Pass 2:
xvid_encraw -bitrate 2300 -pass2 -threads 3 -progress -qpel -gmc -i file.avs -mkv file.mkv

[foxyshadis]

How many fps do you get if you load the script into virtualdub and hit "run video analysis pass"? That's the maximum upper bound. Using the multithreaded avisynth and appropriate syntax can help. I suspect most of the speed hit comes from TDecimate, but there's not much you can do about that. And of course gmc - didn't I read somewhere that gmc wasn't multithreaded?

If speed is of the utmost importance, you can always do a lossless pre-render.

[squid_80]

xvid_encraw reports the xvidcore version and the number of threads being used. Can you post this information?

[elfurbe]

xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


xvid [warn]: Can't find xvid_plugin_ssim, ssim calculations will be disabled
Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [info]: Input is 960 x 544, 23.976fps (24000/1001), starting from frame 0
xvid [info]: Number of frames to encode: 62979, Bitrate = 2235kbps
xvid [info]: xvidcore build version: xvid-1.1.0
xvid [info]: Bitstream version: 1.1.0
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 3DNOW 3DNOWEXT TSC
xvid [info]: Detected 0 cpus, using 3 threads.

That's what she outputs on start, but in Task Manager it shows 1 thread.

I don't use virtual dub for anything in my encoding chain, so I wouldn't even know how to go about doing what you're talking about.

I ran another encode this morning, and it looks like I underestimated my -turbo pass, it's getting about 32fps which isn't terrible, but pass two is still super slow.

[squid_80]

xvid [info]: xvidcore build version: xvid-1.1.0
xvid [info]: Detected 0 cpus, using 3 threads.
You need xvid 1.2.0 for multithreading.

(Also, note to self: Try changing "using x threads" to "requesting x threads" and append "x threads being used", if possible. Also remove ssim warning unless ssim calculations are specifically requested.)

[elfurbe]

Well, that could certainly do it, I suppose. Is this:
http://www.koepi.org/XviD-1.2.-127-25022006.exe
what I need to install?

I guess I thought the xvid encoder was rolled into the xvid_encraw binary, a-la x264.exe. Is that not the case?

[squid_80]

Well, that could certainly do it, I suppose. Is this:
http://www.koepi.org/XviD-1.2.-127-25022006.exe
what I need to install?Yep, that should work.
I guess I thought the xvid encoder was rolled into the xvid_encraw binary, a-la x264.exe. Is that not the case?No, it uses whatever xvidcore.dll it can find. It helps keep the filesize down a bit and makes it possible to update the core encoder without updating xvid_encraw.exe.

[elfurbe]

So if I put xvidcore.dll in the same folder as xvid_encraw, would that be the default one it uses or does it check system first?

[squid_80]

Yes, if xvidcore.dll is in the same directory as xvid_encraw.exe it will be used. At least I'm pretty sure that's how windows dll loading rules work.

[elfurbe]

Alright, threw the xvidcore.dll from xvid 1.2 in there, and rolled it out, got this on start:
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


xvid [warn]: Can't find xvid_plugin_ssim, ssim calculations will be disabled
Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [info]: Input is 960 x 544, 23.976fps (24000/1001), starting from frame 0
xvid [info]: Number of frames to encode: 62994, Bitrate = 2234kbps
xvid [info]: xvidcore build version: xvid-1.2.0-dev
xvid [info]: Bitstream version: 1.2.-127
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
xvid [info]: Detected 2 cpus, using 3 threads.

This is on my computer at work, Core Duo so no 3DNOW, but I've found encoding speeds are similar to my 4400+. Anyway, I'm seeing better first pass (40fps at the moment), but the thread count still stays at 1. I do occasionally see it jump to three, but then right back to one instantly. Is that normal behavior?

[squid_80]

(I never noticed task manager had a thread count column available till now, duh.)

Yes that's normal behaviour. x264 does the same sort of thing.

[elfurbe]

Neat. My second pass encode speed is up to 12fps or so, which is obviously much better. I suppose my expectations are a little off, as I usually deal with anamorphic DVD conversions to x264, but man this seems slow. Does this seem like a reasonable speed for a 1.8GHz Core Duo on pass 2 for this frame size?

[squid_80]

New build is available (http://members.optusnet.com.au/squid_80/xvid_encraw.zip).

Cosmetic changes only:
- fps figures should be more accurate (the time taken to fetch the input frame is included)
- ssim warning should only be displayed if ssim options are used and they are unavailable (in which case it is treated as an error)
- zones help, available via "-help zones". Also displayed if an error is detected in the -zones string
- frame/file sizes are 64-bit integers so there should be no more negative numbers when the output filesize goes over 2gb
- changed the help text for -o to reflect that it can be used for .avi and .mkv
- changed the xvid[info] threads text, still needs a little tweak to distinguish between how many threads are requested vs. how many are actually being used (hint: if detected cpus is 0, multi-threading is probably not available)

[henryho_hk]

Excellent. ^_^ I recall that I once did a 20G encode. The numbers went positive, negative, positive, negative .....

Is your next move putting the input and output in separate threads?

[squid_80]

It's one of the ideas I have. I don't know if there will be much improvement since cpu usage normally already hits 100% if you're using MT avisynth. Elfurbe's posts raise the point that the extra threads for multithreading are created/destroyed for each frame; I'm wondering if that's causing an overhead penalty that can be avoided.

[elfurbe]

Didn't know there was a multithreaded AviSynth, downloaded and installed for the win. Interesting thing though. I added a multithread on the TDecimate filter, since I expected that it was the heaviest non-resizing filter in my chain, and it spawns more threads, now my thread count sits around 3 the whole time, but my cpu usage only barely climbs above 50% indicating that it's not really getting into the second core at all. It basically doesn't matter what I do with thread counts in both places, I can't get more than 53% CPU usage. Wondering what you make of that?

Also, I threw the new version of xvid_encraw in and my framerate went to the toilet. I went from doing 30-40 for this file (with/without MT avis) to doing 12. Switching back to the last version puts the framerates right back up. Is it just a display bug?

[squid_80]

I went from doing 30-40 for this file (with/without MT avis) to doing 12. Switching back to the last version puts the framerates right back up. Is it just a display bug?
The difference between the old/new versions is that the old version only measured the time taken by xvid to encode the frame, whereas the new version measures the time taken to retrieve the input frame and encode it. So (given your script) the time reported by the new version is encoding time + mpeg2 decoding + selecteven (negligible?) + tdecimate + resizing + undot. What you could do is try short encodes (e.g. try adding -frames 2000) with both versions and manually time them (don't rely on the times reported by xvid_encraw). The actual time taken should be the same, and the fps reported by the new xvid_encraw should prove more accurate if you work it out by hand.

[SealTooGreat]

Can someone suggest me up-to-date GUI for xvid_encraw?!

[Adub]

MeGUI.

[squid_80]

Virtualdub and xvid's vfw interface. The idea of encraw was to make all the vfw options available via command line, making a gui for it seems a bit backwards.

[elguaxo]

I want to run encraw with the -ssim_file option, but I'm getting this error: Can't find xvid_plugin_ssim

Do I need a newer xvidcore.dll? Where can I get one that supports this? Thanks!

[squid_80]

Get an updated build from celtic_druid: http://ffdshow.faireal.net/mirror/XviD/
Go for the build with the most recent date. :)

[elguaxo]

Perfect. Thanks!

[smok3]

squid_80: what is the correct latest file?

[henryho_hk]

squid_80, I have recently “upgraded” my Core2Duo (1.86GHz) + 865PE + 1GB DDR-I-400 to Core2Duo (@3GHz) + P965 + 2GB DDR-II-800@860. You know what; the encoding speed does not get increased! Same script (mpeg2source + colormatrix + tdeint + bicubicresize + degrainmedian => 25fps ) I must have messed something up….

[squid_80]

That's weird. Try using -threads 1 on both machines and see if there's a difference.