I made a new SimpleResize filter

[trbarry]

Hi -

I've noticed that much CPU is spent doing resize so I made a new SimpleResize Avisynth filter. This is not as general purpose or elegant as some of the others but it is somewhat faster and should give decent unfiltered results for downsizing.

It also can do non-linear vertical and horizontal stretch/squeeze.

The source and the SimpleResize.dll can be found at www.trbarry.com/SimpleResize.zip

The readme is at www.trbarry.com/Readme_SimpleResize.txt but for the most part I've also just included it below.

- Tom

********************************************************************
File: Readme_SimpleResize.txt
SimpleResize is an Avisynth filter that will do a very simple 2 tap
linear interpolation. It is unfiltered which means it will not soften much. It's main advantage is that it will run somewhat faster than some of the others.

To use it just:

1) Place the SimpleResize.dll in a directory somewhere. You can get it from www.trbarry.com/SimpleResize.zip

2) In you Avisynth file use command similar to

LoadPlugin("F:\SimpleResize\SimpleResize.dll")
Avisource("D:\wherever\myfile.avi")
SimpleResize(width,height)

Of course replace the file and directory names with your own and supply the integer values for width & height.

SimpleResize should run on all MMX machines. It has also has some added (optional) code for SSE2 instructions for when it is running on a P4, though it could certainly use some more. I also anticipate adding some MMXSSE support for P3 & Athlon processors. But sorry, no plans for extra 3DNow code.

WarpedResize

WarpedResize is also included in the SimpleResize.dll. WarpedResize will do a non-linear stretch/squeeze in both the horizontal and vertical dimensions. This can be useful when you want to change the aspect ratio of a video clip and have it mostly distorted at the top, bottom, and side edges. This is mostly experimental but I added it because it required few code changes and almost Zero performance penalty. Use as:

LoadPlugin("F:\SimpleResize\SimpleResize.dll")
Avisource("D:\wherever\myfile.avi")
WarpedResize(width,height,hWarp,vWarp)

where hWarp & vWarp are the horizontal and vertical warp factors. These are real number, usually between .8 and 1.3 that are basically just an exponent to determine how non-linear you really want the output.

Values above 1.0 cause the output image to be stretched more in the middle and squeezed at the edges. Values below 1.0 will do the reverse. Specifying 1.0 for either of them will do a linear resize in that dimension, just as you would get using SimpleResize. Values far from 1.0 will give some very strange results. See the "Notes to Mathematicians" below.

One reason to use WarpedResize would be when you have a clip with a 16:9 aspect ratio and want to resize it for a 4:3 aspect ratio display without either clipping off valuable info or having to display black bars. (or vice versa)

An example image of using WarpedResize for this can be found (for now) at

www.trbarry.com/WarpTest.jpg.

This image was from a short HDTV digital capture that was at a 1280x720 resolution, a 16:9 aspect ratio. It was downsized and warped to a 640x480 4:3 aspect ratio using the following script command:

WarpedResize(640,480,1.15,0.95))


Current limitations, for SimpleResize/WarpedResize:

1) Only YUY2 color mode is currently supported. Add a ConvertToYuY2 command first if needed.

2) The target width must be a multiple of 4 pixels.

3) It will run faster on SSE2 machines if the target width is a multiple of 8 pixels and if the data starts on an 8 pixel boundary. I don't know if prior Clip() commands affect this or not.

4) If anyone knows how to make a DirectShow filter out of this I'd sure like to have one. ;-)


Notes to Mathematicians: (and questions)

Imagine the screen was dimensions that went from -1.0 to 1.0. We'll only consider the horizontal dimension for the moment and only the right hand half of the screen. Assume we want to calculate the value of an output pixel at location x, where 0 <= x <=1.

The output value will be the source value from the input screen with the same dimensions, at location s. Right now I'm just calculating s = .3 x + .7 (x^w), where w is the warp factor mentioned above. This gets the job done and produces smooth numbers from 0 to one, without too much distortion as long as w is close to 1.0.

The first term is just to make sure the derivative doesn't go to zero which would produce infinite stretching. The same formula is reflected for the left half of the screen.

Now this seems to get the job done and works fine for values above 1. But for values slightly below 1 I'm not so sure. I think we need a function where:

1) The results are smoothly increasing 0 <= s <= 1

2) The first derivative is never 0 or infinite

3) The warpage is mostly toward the edges.

Now, as near as I can tell the warpage (coined term) is more or less just the absolute value of the second derivative. So if we wanted the warpage to be small when x = 0 and to grow toward the edges, what could be a useful warp function?

It is easy to drop in another warp function. And there is no performance penalty either way because it's just calculated and tabled at startup. After that it runs at the same speed as SimpleResize.

Anyone have any ideas?

[Blight]

Barry, while it's useful to have a faster resize filter for avisynth, a good one for VDub is also useful since it's a lot easier (user-wise) to resize in VDub. Might have some overhead, but still...

[trbarry]

Hi Blight -

I wrote this mostly for speed. I don't think it can improve quality over the appropriate bicubic resize in any cases except maybe where you really don't want any filtering. This might be for a HDTV capture with no noise that was already highly filtered and you don't want any more. But so far I think that leaves an audience of about 1, me.

And Vdub works in RGB mode. I haven't even implemented RGB SimpleResize yet. And finally, I've never written a Virtualdub filter. So I'm much more likely to do DVD2AVI and maybe even DirectShow support first.

- Tom

[trbarry]

Oops, just corrected a period on the link of my WarpedResize sample image (16:9 image on a 4:3 screen):

www.trbarry.com/WarpTest.jpg

- Tom

[DDogg]

Tom, I ran a few tests. You done might good :)

Baseline Bicubic .0,.60 1.35 Realtime CCE 2.5
SimpleResize 1.73 Realtime CCE 2.5

Video results were excellent to me, although my eyes are not good for judging and the segment was dark to begin with.

Machine Slightly OC 1.4 T-Bird
source DVD resize to 480x360

Standard Script used:

LoadPlugin("C:\PROGRA~1\DVD2SVCD\MPEG2Dec\mpeg2dec.dll")
LoadPlugin("SimpleResize.dll")
mpeg2source("D:\matrix\DVD2AV~1.D2V")
SimpleResize(480,360) or Bicubic (480,360,0,60)
AddBorders(0,60,0,60)

[trbarry]

DDogg -

Uhhhhhh, I'm almost afraid to ask, but I don't have CCE. Larger numbers are better, right?

I hope. ;)

- Tom

[kdiddy]

Well I didnt get quite the gain that DDogg got..mine went up from 1.25 to 1.38 avg...havent had a chance to look at on my TV as of yet to see any visual differences..

@DDogg

Im curious to know what chipset & ram you are running, and how overclocked are you??...I am running athlon XP 1600 SIS 735 chipset, ATA100, 256 DDR2100 RAM...and best Ive gotten at that resize is 1.4...I would assume that the XP 1600 (1.4GHz) would perform on par or better than a tbird 1.4 considering the extra SSE instructions...unless there are some other CCE secrets you emply that I dont know of... hmmmm maybe the anit-noise filter I use..I dont know, was just curious.

[DDogg]

Tom, yes, I was getting 1.7 realtime meaning a hours worth of source would take around 35 mins to encode.

kdidy, epox 266A< with 512 ddr 4-way interleaved. Buss speed is kicked to 150. No noise filters.

Infact, I did not mention, when I added TS 1,2 my speed dropped to .8 from 1.7. Any noise filter will slow you down a lot.

I think increasing the speed of the buss and thus making the memory run faster really makes a disproportionate difference with CCE.

SiSoft shows my FPU ram bandwidth at 904.

[kdiddy]

yeah it would be the FSB speed...mine only does about 650 FPU....dont think I have the proper cooling to propell mine to 150, LOL,..I dont use temporal smoother, I never been able to notice any "considerable" gains when you factor in the amount time you gain int he encoding process....I drop the anti-noise filter as well..but again, it didnt improve my time....thanks for the info.

[DDogg]

Tom, I have asked some folks in the dvd2svcd advanced forum to test your new filter. It really looks promising. In case nobody said it, "Thanks for working on this".
http://rilanparty.com/vbb/showthread.php?s=&threadid=14793
DD

[trbarry]

DD -

I know more or less nothing about dvd2svcd, but maybe I should. I'll monitor that thread.

- Tom

[DDogg]

Tom, is there anyway to further optimize the temporalsmoother code to you knowledge? Would it yield an opportunity for further optimization if it were incorporated directly into a resizing filter?

Simple resize 1.72 RT
Simple resize with TS 1,2 .85 RT

So a big hit is taken on speed. Just curuous if you have an opinion on this as I know you have some knowledge on the subject.

[trbarry]

DDogg -

I don't really have any knowledge about TemporalSmoother. I just took a look at the code in mpeg2dec, if that's the one you mean. Anything can be optimized but I'm afraid this one is already done in SSEMMX so the easy pickens are already gone.

I don't understand the algorithm enough to know how much more can be squeezed out of it but it looked like pretty sophisticated code already. I did notice it had loops nested 3 deep / frame, which is not usually a good sign.

There are also some newer real time filters in DScaler. If any of them would do the job we could consider porting to Avisynth. Even my WarpedResize was an idea I first tried for DScaler but never released.

But I pretty often throw away the first one of everything I write for myself.

- Tom

[DDogg]

Here is what I am thinking, but please bear with the simplistic rambling. I am formost a tool user with very little understanding of the guts of what we do, but I think I do have a decent grip on what we need.

We are all about compressing very complex video with a very limited bitrate. It stikes me that a concerted effort directed toward a combination resizing/"compression maximizing" filter would be of great benefit. It also strikes me that if the two operations were combined, and the interaction of the two needs were optimized we would have a chance to significantly improve the ability to encode action shots with minimum bitrate and the following reduction in blocky jaggies (is that really a proper descriptive phrase? ;)). Hopefully without too much of a speed hit (like 25% instead of 45%).

My personal use of TemporalSmoother 1,2 or 2,1 is all about increasing compressability rather than actually effecting the appearence of the video.

Obviously we want the precious bitrate that we have to be used to store the person moving his arm and not to be divided between the arm movement and the existing small noise randomness of the frames.

Well, that is the seed of my thought train. Using a combination of TS 1,2 and your SimpleResize seems to really help compressability without impacting the resuling video, but the speed really takes a beating by about 40-50%. If that speed hit could be reduced somehow (the how is beyond my understanding) we would be golden.

I do think this might, at least, be a topic worth consideration by some of you coding experts.

[bb]

Well, I indeed NEED to improve image quality: for TV captures and for DV camcorder.

@trbarry: Do you think it would be a significant speed improvement if one would combine spatial and temporal smoothing into a single filter?

bb

[trbarry]

@trbarry: Do you think it would be a significant speed improvement if one would combine spatial and temporal smoothing into a single filter?

I don't know the code there enough to say for sure but my own guess is that, yes, a combo clip/spatial/temporal/resize would run somewhat faster then all separately.

This is mostly because of memory access speed but also because you can store intermediate results in a more useful form. But I could get surprised here. The first version of SimpleResize I wrote did everything in a single pass but it turned out to be faster if I stored a work form of one line at a time of vertical resize output. But maybe I just had a bug in the first one.

But the moment someone only wanted clip/temporal/resize then the speed advantage might be lost again. Dunno.

- Tom

[DDogg]

Well, if nothing else, perhaps this discussion might plant a seed somewhere with someone.

[DJ Bobo]

Well, I tried the SimpleResize filter and I must say, I' m not satisfied with it.

SimpleResize is faster than Bilinear or Bicubic, but it produces too sharp pictures, I get annoying jaggies in the video and that makes the compression harder, about 27% more bitrate is needed!!!

Compressing one minute of (704x480 to) 384x288 23,976fps video using DivX 4.12 1-pass quality based slowest 100%-quality gave me:

Bilinear: 21,6 MB
Bicubic: 22,1 MB
Simple: 27,5 MB (!!!)

[trbarry]

Sorry to hear that.

SimpleResize provides no filtering (or sharpening) so if you need that you either have to add some or use a more softening resize.

- Tom

[trbarry]

Version 0.2 of my SimpleResize Avisynth filter is now out, see: www.trbarry.com/SimpleResize.zip

There is also a readme/changelog at: www.trbarry.com/Readme_SimpleResize.txt

Like before, it is unclear how long that stuff will be there as I am caught up in the ATT <-> Comcast conversions.

Changes include a better warp calculation formula for WarpedResize and some more SSE2 and SSEMMX enhancements. Thanks to DmitryR for his insightful tuning suggestions.

There may be a tiny improvement for P4 users but P3/Athlon users might see a 3-5% speed increase based upon the total time of a job with no other filters. (over v 0.1)

There hasn't really been much interest in the WarpedResize function but I improved the warp formula somewhat, making the curvature always zero at the center of the screen and increasing the stretch or squeeze towards the edges. And it has no performance hit.

We used to have some requests for this on the DScaler project where folks with widescreen 16:9 aspect ratio TV's would want to avoid the burn-in caused by black bars when showing a 4:3 picture. I already posted a demo of the reverse of this above but I also made one showing how you can warp a 4:3 picture to take up all of a 16:9 screen and still have it not look too bad in the center.

See www.trbarry.com/WarpTest2.jpg for the results.

Still just a curiousity but maybe it would be useful if I made a DirectShow version of it.

- Tom

[GZZ]

Thanks for nice new version. I just tryed it on movie I was about to start encoding and the speed was the same as the old version.

I´m getting 1.25 in CCE with this script:

LoadPlugin("E:\Movie\MPEG2DEC.dll")
Mpeg2source("E:\Movie\DVD2AVI.d2v")
LoadPlugin("D:\Movie\SimpleResize\SimpleResize.dll")
LoadPlugin("C:\WINDOWS\system32\vobsub.dll")
ResampleAudio(44100)
SimpleResize(480,432)
AddBorders(0,72,0,72)
VobSub("E:\Movie\VTS_01_0")


Don't know if I get better speed if I move the simpleresizer up before I load the D2v file or maybe down.

But thanks for the new version.

My machine is:

AthlonXP 1900+ (1600 mhz)
Abit KR7A
512 mb Crurical DDR ram
Windows XP PRO

GZZ

[trbarry]

GZZ -

I dunno. I only did timings on a P3 & P4 but I thought the Athlon would also get the P3 improvement. But it's hard to notice a couple percent when any other processing is involved.

What version of Avisynth are you running? I've been meaning to check if older versions even tell us about faster processors.

Does anyone else know this?

- Tom

[GZZ]

I´m using the Avisynth Beta 5.0

Here is a direct link to it:

http://www.horizon.nl/~michel/bin/Avisynthv105.zip

It have some improvet Avi handling. I works better then Avisynth 1.0 for AVI files.

But I mainly use SimpleResizer together with DVD movies.

GZZ

[trbarry]

I was testing against 1.05, so it's not that.

Either Athlon's don't get the improvement or any improvement was dwarfed by one of the other filters.

Ask a dumb question, though. If you right click on the SimpleResize.dll and choose properties doe the version say 0.2.0.0?

Maybe I put the wrong one out there or something. Or you got it so soon that some server had it cached.

- Tom

[oddball]

Yup. A DirectShow filter that uses low CPU would be welcome with little quality loss would be welcome. I am still looking for the AudioServe funtionality that is lacking in Avisynth at present more than anything though. Using a seperate wave file (AudioDub) is really crap. Sync probs and extracting/converting is a pain. If I could AudioServe I could do some neat tricks with my Matrox G400 TV out (Like playback SVCD's with sound in a fake widescreen anamorphic squeeze):)

[GZZ]

hmm - I don't know if it my System or just Simpleresizer (the new version ONLY) which is bad.

But I tryed your new version and CCE keep Stopping and just stands there after a few procent. Then I change back to version 1 (the first one you made) and now I got twice as long in my encoding then before and CCE looks stabel again.

I don't know if this is pure luck or just a bug in simpleresizer.

I will report back if it crash with the old version of simpleresizer.

PS: I was the new version I got from you, it said version 0.2.0.0.

GZZ

[GZZ]

Sorry for previus post. Its was not Simpleresizers fault.

I haven't located the problem yet. But I´m reading some other post made by other people with the same freeze problem in CCE.

GZZ

[trbarry]

GZZ -

Good. I'm glad S-R was not the culprit. But I'm still concerned that Athlon performance didn't pick up as much as P3. If I can pry my son of his Duron for awhile maybe I can try it there.

Or if anyone wants I can post a version that just assumes SSE support no matter what Avisynth says and we can test that.

Though I guess it is possible that with a larger cache size things like prefetch don't help as much on Athlon as it's maybe already faster in cases like this than a P3.

On a P4 any improvement in v 0.2 over 0.1 is mostly lost in the noise but I already had most of the P4 SSE2 code in the first version. But on a 866 P3 I get a repeatable 4.4% improvement on one simple test over v 0.1.

- Tom

[DDogg]

Edited my confusion out :)

Later: Very sorry to say it looks like they are exactly the same speed although that speed is awesome.

Both took 9min 05 sec to do a four pass encode at at average speed of 1.80 realtime.

Script for new:
LoadPlugin("C:\PROGRA~1\DVD2SVCD\SIMPLE~1\SIMPLEresize.DLL")
LoadPlugin("C:\PROGRA~1\DVD2SVCD\MPEG2Dec\mpeg2dec.dll")
mpeg2source("D:\TEMP_T~1\DVD2AV~1.D2V")
SimpleResize(480,480)
ResampleAudio(44100

Script for old:
LoadPlugin("C:\PROGRA~1\DVD2SVCD\SIMPLE~1\SIMPLEresize_old.DLL")
LoadPlugin("C:\PROGRA~1\DVD2SVCD\MPEG2Dec\mpeg2dec.dll")
mpeg2source("D:\TEMP_T~1\DVD2AV~1.D2V")
SimpleResize(480,480)
ResampleAudio(44100)

Machine:1.4 TBird FSB at 150

[trbarry]

DDogg -

If you or anyone post timings, please say which processor you are using. From some reports I am starting to think the performance improvements will apply only/mostly to P3's and many faster Celeron processors (> 550 mhz, and I'm not even sure abut these)

No one has reported any improvement for Athlon/Duron and I didn't expect anything noticable for P4 which was mostly optimized the first release.

But I'm still curious why it doesn't seem to be as much of an improvement for Athlon/Durons.

- Tom

[b0b0b0b]

Why did bobotns get jaggies after resizing? Is this a risk that comes with using simpleresize?

When there's motion, will moving edges in the output shimmer?

[roy]

I got green line on the right side of the movie, only when I use this filter. When I use any other everything is ok.

This is my second movie when I use this filter. With previous everything was ok.

Why get I this time this green line on the right edge of the movie?

[ARDA]

From SimpleResize txt

Current limitations, for SimpleResize/WarpedResize:

1) Only YUY2 color mode is currently supported. Add a ConvertToYuY2 command first if needed.
2) The target width must be a multiple of 4 pixels
3) It will run faster on SSE2 machines if the target width is a multiple of 8pixels and if the data starts on an 8 pixel boundary. I don't know if prior Clip() commands affect this or not.
4) If anyone knows how to make a DirectShow filter out of this I'd sure like to have one. ;-)
Look carefully the size of your frame

[trbarry]

Why did bobotns get jaggies after resizing? Is this a risk that comes with using simpleresize?

b0b0b0b0 -
Downsizing can create high frequency components (sharper edges) that are harder to compress, and he was using 100% quality mode. The other resizes do some filtering but I did not with SimpleResize, both for performance and because everything else in the world seems also to add a bit more filtering. I wanted with no filtering or sharpening.

But yes, if you are going to use low bit rates on a noisy source with no other filters then you are likely better off with the softer BiLinearResize, or I guess maybe SoftBicubic.

But I've mostly been working recently with digital TV or HDTV captures where the source is very clean but may already have been filtered a bit. So YMMV.

And I could be missing something but I dont think this should have anything to do with moving edges. That is usually a deinterlace related problem. SimpleResize currently assumes you have already made progressive frames before resize using GreedyHMA, Decomb, etc. But if you soften things enough it hides jaggies.

I did discuss making a InterlacedResize above but have not done anything on it yet. There seemed to be limited interest but I'll play with it sometime.

- Tom

[trbarry]

I got green line on the right side of the movie, only when I use this filter. When I use any other everything is ok.

That does sound like an error in pixels/4 size. But I thought on SimpleResize (unlike GreedyHMA) I put in a check and an error message for that. ???

Could you post your filter script? What was the input & output widths?

- Tom

[roy]

Thanks

I have solved the problem.

In GordianKnot on the tab Resolution I changed crop parametrs to:
Top=72, Bottom=72. left=12 and right=12, from Top=71, Bottom=73, left= 14 and right=8.

And now everything is ok.

I have Athlon XP 1600+ and speed improvment is graet about 20%. Good work.

[dvd2svcd]

trbarry: I just want to thank you for this great filter, it works very well and is very fast :) I was wondering if there's anywhere I can donate a few bucks to you for your great effort?

(P.S. Would you consider making an "addborder" option in SimpleResize?)

[DDogg]

"SimpleResize currently assumes you have already made progressive frames before resize ..."

I assume this is stating the obvious, but you would not then suggest this resizing method be used on DVCAM-AVI (NTSC-true Intl.)?

"I did discuss making a InterlacedResize above but have not done anything on it yet. There seemed to be limited interest but I'll play with it sometime."

Waving hand! Me, me.

[trbarry]

trbarry: I just want to thank you for this great filter, it works very well and is very fast I was wondering if there's anywhere I can donate a few bucks to you for your great effort?

(P.S. Would you consider making an "addborder" option in SimpleResize?)

Thanks very much for your kind comments. I'm not really set up to take personal donations but see my comments about "Philanthropy-Ware" and the Electronic Frontier Foundation in the readme file.

And does AddBorders take up enough processor time to bother to optimize it? I never timed it but thought both it and crop were fast enough to not bother to add them in here. But I could be way wrong and haven't used it much or researched it at all.

- Tom

[trbarry]

I assume this is stating the obvious, but you would not then suggest this resizing method be used on DVCAM-AVI (NTSC-true Intl.)?


DDogg -

SimpleResize doen't work with interlaced material any worse than the other methods do ... it just doesn't do it any better. ;)

IMHO, any of them that I'm aware of will either blend the two fields together somewhat or resize them separately using the wrong coordinates. Neither way is optimal.

BTW, I've been refering to my discussion "above" but had my threads mixed up. I actually was soliciting comments on InterlacedResize in
this thread (http://rilanparty.com/vbb/showthread.php?s=&threadid=13488).

I'm not totally certain my idea will work properly but I'm pretty sure. I'll go ahead an make it and we can find out. I'll just add it as another entry point to SimpleResize.

- Tom

[dvd2svcd]

@trbarry: Regarding the AddBorder feature. I have a difference of 0.2 in speed in CCE between using Addborders and not. I know that it isn't much, but it is a couple of hours additional encoding time when doing longer movies.

[trbarry]

dvd2svcd -

Strange. I'll take a look at what Avisynth is doing there. Maybe it's just C++ code that no one else bothered to optimize either. But not tonite, I just ran out of energy, or coffee, or something. But it's not out of the question to either add it to SimpleResize or make an optimized one, or both.

Is this Avisynth beta 5?

- Tom

[DDogg]

"I'm not totally certain my idea will work properly but I'm pretty sure. I'll go ahead an make it and we can find out. "

Tom, you gotta be a glutton for "Yet Another F'ing Learning Opportunity" :)

All kidding aside, I sure would like to try it.

[dvd2svcd]

@trbarry:

Yes, I am using Avisynth 1.05 :)

[dvd2svcd]

Strange, it seems that the new version of SimpleResize actually is a bit slower than BicubicResize. I tried it on both an Athlon, PIII and P4. The older versions was much faster. Is this just me or has anybody else noticed that?

[trbarry]

Too strange.

Maybe I put the debug version out there or something stupid. I'll check. On my systems with v 0.2 the P4 is negligably faster, the P3 is 2-5% faster and I still have not tested on my sons Duron.

But except for the silly WarpedResize there are no bug fixes in v 0.2 and I've still got v 0.1 for non-P3 users if it really is faster in any case.

It's easily possible because of the different (and larger?) cache architecture that the prefetch instructions I used just add overhead to Athlon performance without helping much.

But I can certainly see the difference on P3's here so I guess I'll download copies of my own modules and see if that matches.

Though we should remember that short sequential tests one after the other maybe don't always give the exact same results, due both to disk caching and cpu temperature considerations.

BTW, I actually wrote a bunch of new code for v 0.2 but then ended up tearing much of it back out again because it just seemed to add complication without any performance improvement. Maybe I tore out too much.

- Tom

[dvd2svcd]

@trbarry:

I did a new compile of SimpleResize and made a filecompare, and it is not a Debug version you have released, so that's not the problem. However, I made some compile and link optimization in Visual C++ which gave me an additional 0.08 in CCE (from 0.610 to 0.690). I know it isn't much but I figure that any speed increase is good. I dunno if you want the settings I use in VC++, if so I can mail them to you.

[Guest]

@dvd2svcd

Please, what are the setting changes you make to get this improvment?
Thank you.

[dvd2svcd]

Well, first of all I want to say that VC++ isn't my normal Environment so I might not always know what I am doing. My preferred language is delphi. Anyway, what I did was fairly simple:

In Settings | Tab C/C++ | Precompiled Headers I just selected "Not Using precompiled headers"

Besides that, I use DirectX 8.1 SDK libraries. So as you can see it isn't much I have done but it helped.

[trbarry]

dvd2svcd -

Good find. I'm not sure how/if precompiled headers affects performance but if they do I'll certainly turn them off. I wonder if what is in those headers that can use any cpu time? Dunno. I don't even know when precompiled headers get (re)compiled or what options are used for them.

I wonder if there is anything in them now that changes default data alignment. That could be a biggie. Anybody?

And I don't think that SimpleResize would refer to anything in the DirectX SDK. I have it installed but I don't think currently in the include or lib list.

But yes, please email any findings like this to me at trbarry@trbarry.com. I need all the help I can get.

- Tom