I made a new SimpleResize filter [Archive]

trbarry

20th January 2002, 23:16

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

21st January 2002, 06:46

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

21st January 2002, 16:56

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

21st January 2002, 16:58

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

22nd January 2002, 05:51

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

22nd January 2002, 06:50

DDogg -

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

I hope. ;)

- Tom

kdiddy

22nd January 2002, 10:09

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

22nd January 2002, 16:33

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

22nd January 2002, 18:54

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

24th January 2002, 16:39

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

24th January 2002, 16:55

DD -

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

- Tom

DDogg

24th January 2002, 17:22

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

24th January 2002, 21:30

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

24th January 2002, 23:14

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.

25th January 2002, 08:58

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

25th January 2002, 17:56

@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

25th January 2002, 20:11

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

DJ Bobo

25th January 2002, 23:17

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

26th January 2002, 02:02

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

31st January 2002, 19:08

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

31st January 2002, 19:20

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

31st January 2002, 20:11

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

31st January 2002, 20:16

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

31st January 2002, 20:23

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

31st January 2002, 21:11

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

31st January 2002, 22:26

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

31st January 2002, 22:59

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

1st February 2002, 01:34

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

1st February 2002, 02:42

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

1st February 2002, 03:00

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

1st February 2002, 17:18

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

1st February 2002, 19:38

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

1st February 2002, 20:02

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

1st February 2002, 21:20

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

1st February 2002, 21:23

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

1st February 2002, 21:38

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

1st February 2002, 21:38

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

2nd February 2002, 00:32

"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

2nd February 2002, 04:06

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

2nd February 2002, 04:21

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

2nd February 2002, 07:02

@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

2nd February 2002, 07:15

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

2nd February 2002, 07:28

"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

2nd February 2002, 07:30

@trbarry:

Yes, I am using Avisynth 1.05 :)

dvd2svcd

2nd February 2002, 17:31

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

2nd February 2002, 20:19

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

3rd February 2002, 15:47

@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.

neuron2

3rd February 2002, 16:20

@dvd2svcd

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

dvd2svcd

3rd February 2002, 17:00

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

3rd February 2002, 18:22

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

trbarry

3rd February 2002, 18:44

I also looked into the performance of AddBorders. I think it does seem to make another copy of the image, which has some performance effect. I'm still not sure whether crop does that also.

For performance (but not user friendliness) considerations I'm considering adding an additional couple of commands to SimpleResize:

InterlacedResize(Width, Height)

and

NotSimpleResize(OutWidth, OutHeight,
CropLeft, CropTop, CropWidth, CropHeight,
LeftBorder, TopBorder, RightBorder, BottomBorder,
HwarpFactor, VWarpFactor, InterlacedFlag)

This would add interlaced support and the Crop and AddBorders functions with the same parms as Avisynth currently uses. Crop may be unneeded if it turns out it already runs instntly without making another copy of the data. I'll check.

The 2nd parm list would be as confusing as GreedyHMA, but it would run fast. ;)

Comments?

- Tom

dvd2svcd

3rd February 2002, 18:53

Maybe also a Boolean for Addingborders/cropping before or after resizing.

trbarry

3rd February 2002, 20:29

Maybe also a Boolean for Addingborders/cropping before or after resizing

DVD2SVCD -

My first intention (out of programming laziness) was to crop first, which speeds things up by having less data to resize. Crop of course means do nothing, just not process some data, so it is just pushing pointers.

I was then going to simultaneously resize into the center of the output area and add any needed borders. But most of this was just for speed and the programming convenience of how easily it would fit into my existing code. And offhand I can't come up with any example that it couldn't handle if I did it this way.

Does this way create any problems? If so, could you give an example to solve?

I somewhat wanted to leave it undefined because depending upon the cropping I may be able to play games with the data alignment this way. Stuff runs faster on a 16 byte boundary so sometimes it may be possible to run a little faster if I resize some of the cropped area. I confess I have not really thought that part through properly yet. That was one reason I considered an integrated crop but there are probably many ways to do it that might not take much more work.

I don't suppose anyone knows how to easily make Avisynth filters accept keyword parameters with defaults. That would certainly make the interface easier to use.

- Tom

neuron2

3rd February 2002, 20:45

>>I don't suppose anyone knows how to easily make Avisynth filters accept keyword parameters with defaults. That would certainly make the interface easier to use.

What do you mean by this? In Decomb, you can say things like:

Telecide(blend=false,postprocess=true)

with the parameters in any order and combination (any can be omitted or included). Is that what you mean? If so that is easy using existing Avisynth kernel features. If not, what do you mean?

An alternative would be to do everything with a string:

Telecide("blend,postprocess,threshold=10")

Your code would have to parse the string.

dvd2svcd

3rd February 2002, 20:45

I agree Tom, Crop, Resize, Addborders. That is the prime way (and what I always do), and when I think about it, I can't even see a reason to do it any other way.

Reagarding default parameter values, I know that the internal routines (like bicubicresize) has default values, and I thought that you might do it the same way in your filter.

trbarry

3rd February 2002, 21:29

What do you mean by this? In Decomb, you can say things like:

Telecide(blend=false,postprocess=true)

with the parameters in any order and combination (any can be omitted or included). Is that what you mean? If so that is easy using existing Avisynth kernel features. If not, what do you mean?

neuron2 -

Yep, that is indeed what I mean. Did I miss some doc that tells how to do it without writing another command parser? I guess I'll go look again but I don't suppose you'd happen to have a spare link?

And can I mix positional & keyword types? SimpleResize(640, 480, LeftBorder=2) ?

- Tom

neuron2

3rd February 2002, 21:56

@trbarry

I figured it out from reading Ben's document describing the plugin example: avisynth-extensions.html.

It's easy, here's how:

1. Make your plugin init line like this:

env->AddFunction("Telecide", "c[swap]b[firstlast]b[postprocess]
b[threshold]i[blend]b[chroma]b[debug]b", Create_Telecide, 0);

...the things in brackets are the names that will be used.

2. Make your create call as follows:

AVSValue __cdecl Create_Telecide(AVSValue args, void* user_data,
IScriptEnvironment* env) {
return new Telecide(args[0].AsClip(),
args[1].AsBool(false), // swap
args[2].AsBool(false), // firstlast
args[3].AsBool(true), // postprocess
args[4].AsInt(15), // threshold
args[5].AsBool(true), // blend
args[6].AsBool(false), // chroma
args[7].AsBool(false), // debug
env);
}

3. Then do your class as follows:

class Telecide : public GenericVideoFilter
{
bool swap, firstlast, postprocess, blend, chroma, debug;
int threshold;

public:
Telecide::Telecide(PClip _child, bool _swap,
bool _firstlast, bool _postprocess, int _threshold, bool _blend,
bool _chroma, bool _debug, IScriptEnvironment* env) :
GenericVideoFilter(_child), swap(_swap), firstlast
(_firstlast), postprocess(_postprocess), threshold(_threshold),
blend(_blend), chroma(_chroma), debug(_debug)
{
...
}

PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);
};

It seems you can mix, but the positionals will all have to come before the named ones, otherwise the positioning gets confused.

trbarry

3rd February 2002, 22:34

Neuron2 -

Quite nifty. Thanks!

You've probably just written the most compresensive guide to programming Avisynth filter parms that's ever existed.

- Tom

trbarry

4th February 2002, 21:57

Hi -

I have not done any more optimizations or coding for the more complex crop/borders functions yet but I did today release a new version supporting:

InterlacedResize() and
InterlacedWarpedResize()

These are experimental but should support resizing of interlaced video without the usual problems in trying to do that.

I'm going to even break a standard rule here by suggesting that you can sometimes go faster by downsizing before the deinterlace/IVTC step if you so choose. Now it is possible that the way I did it you can theoretically lose a small amount of vertical detail with InterlacedResize but so far I haven't seen it. And it is also possible that InterlacedResize can confuse a subsequent deinterlace/IVTC function but at least with testing GreedyHMA that also does not seem to be a problem. But all this is brand new and YMMV.

The new version 0.3, including DLL & source, is available at www.trbarry.com/SimpleResize.zip

A readme/changelog is in the zip and also at www.trbarry.com/Readme_SimpleResize.txt

As always, I appreciate any feedback.

- Tom

b0b0b0b

6th February 2002, 18:56

Hi Tom I like your idea for interlacedresize.

Does it do a separatefields; resize a; resize b; combinefields; ?

Here are my results:

I tried it on a resize from 720x480 => 320x240 on a straight ntsc interlaced stream and deinterlaced with decomb. No interlace artifacts came through, but the result was a lot more jagged than when I did a straight simpleresize after deinterlace. Doing a bilinearresize after deinterlace came out soft with no jaggies. I don't understand why interlacedresize was more jagged than simpleresize. I will keep thinking about it.

I just now realize I should have done a separatefields and discarded one of them because I ended up halving the vertical resolution.

trbarry

6th February 2002, 20:07

b0b0b0b -

Thanks. AFAIK, you are the only one who has tried it so far.

Does it do a separatefields; resize a; resize b; combinefields; ?

Not exactly. That wouldn't usually produce (quite) the correct results, but it does something similar. It calculates the odd pixel values as an interpolation of other odd values only, but using the coordinates of the whole screen. Same for even.

I tried it on a resize from 720x480 => 320x240 on a straight ntsc interlaced stream and deinterlaced with decomb. No interlace artifacts came through, but the result was a lot more jagged than when I did a straight simpleresize after deinterlace. Doing a bilinearresize after deinterlace came out soft with no jaggies. I don't understand why interlacedresize was more jagged than simpleresize. I will keep thinking about it.

This may be because even SimpleResize will tend to blend a little, though I usually claim it has no additional filtering. But if you blend adjacent odd and even lines after deinterlace it can tend to hide some deinterlace artifacts. So it could be either but keep in mind that, even more than SimpleResize, InterlacedResize won't help you filter or hide defects. Or it may be a bug. ??

And yeah, you can probably go a lot faster and get better results just throwing away a field and forgetting the deinterlace completely.
But in that case I still personally use SimpleResize (after) instead of HorizontalReduceBy2 (if needed) because HRby2 still softens more.

- Tom

trbarry

7th February 2002, 06:56

A bit more thinking about the excess jaggies observed above when doing InterlacedResize before an IVTC or deinterlace process.

It is possible to do an almost perfect IVTC given good material but when there is video interlaced source there will almost always be some jaggies or artifacts introduced. And many of us have tended to use the inherent smoothing of a resize method to somewhat hide these.

So while I still think we can get away with InterlacedResize before IVTC on good film based material I would recommend doing it before deinterlacing video material only under if you turn on the vertical filter option using GreedyHMA or add some other filtering using another deinterlace method. Because I don't make extremely low bit rate encodings I'm usually against a lot of filtering but in some cases I guess it becomes necessary.

Of course if you intend to keep your video interlaced then InterlacedResize may still be your best bet, with or without filtering. I'm not currently aware of others that handle this.

- Tom

Blight

27th February 2002, 20:10

trbarry:
I am in need of adding a high-performance image resizer into ZP (for resizing the DVD/Media folder images.

Is there a way I can use your resizer (considering I'm using delphi)... Is it fully ASM? something I may be able to add as an ASM block inside delphi?

Blight

27th February 2002, 22:15

Hmm, since my understanding of math is limited, I wrote my own fuzzy-math scaler using RGB space and factors. It's got nice quality on down-sizing, but rather bad on upsizing:

procedure DrawBGImage(SrcW{XOfs},SrcH{YOfs},BGWidth,BGHeight : Integer);
type
TMyRGB =
Record
mBlue : Byte;
mGreen : Byte;
mRed : Byte;
End;
TMyScanLine = Array[0..4095] of TMyRGB;

var
Speed1 : Integer;
Speed2 : Integer;
Speed4 : Integer;
PixR : Integer;
PixG : Integer;
PixB : Integer;
SX,SY : Integer;
X,Y : Integer;
PixXShl : Integer;
PixYShl : Integer;
PixXRnd : Integer;
PixYRnd : Integer;
PicWidth : Integer;
PicHeight : Integer;
PixCount : Integer;
PixXPos : Integer;
PixYPos : Integer;
PixX : Real;
PixY : Real;
P : ^TMyScanLine;
PL : Array[0..4095] of ^TMyScanLine;

begin
For Y := 0 to BGBitmap.Height-1 do PL[Y] := BGBitmap.Scanline[Y];
PicWidth := BGBitmap.Width shl 2{Factor};
PicHeight := BGBitmap.Height shl 2{Factor};
PixX := PicWidth / BGWidth;
PixY := PicHeight / BGHeight;
PixCount := Round(PixY)*Round(PixX);
PixXShl := (PicWidth shl 8) div BGWidth;
PixYShl := (PicHeight shl 8) div BGHeight;
PixXRnd := Round(PixX);
PixYRnd := Round(PixY);

For Y := 0 to BGHeight-1 do
Begin
PixYPos := (Y*PixYShl) shr 8;
P := BGImage.Picture.Bitmap.Scanline[Y+SrcH];
For X := 0 to BGWidth-1 do
Begin
PixR := 0;
PixG := 0;
PixB := 0;
PixXPos := (X*PixXShl) shr 8;
For SY := 0 to PixYRnd-1 do
Begin
Speed1 := ((PixYPos+SY) shr 2);
For SX := 0 to PixXRnd-1 do
Begin
Speed2 := (PixXPos+SX) shr 2;
Inc(PixR,PL[Speed1]^[Speed2].MRed);
Inc(PixG,PL[Speed1]^[Speed2].MGreen);
Inc(PixB,PL[Speed1]^[Speed2].MBlue);
End;
End;
Speed4 := X+SrcW;
P^[Speed4].MRed := PixR div PixCount;
P^[Speed4].MGreen := PixG div PixCount;
P^[Speed4].MBlue := PixB div PixCount;
End;
End;
end;

BGBitmap is a TBitmap source image
BGImage is a TImage in which the resized bitmap is written to, with SrcW, SrcY being offsets within that image (since I don't always cover the entire image with the resized image).

I doubt anyone came up with this retarded factor scaling method before, but hey, it works for me! feel free to use ;)

And I bet it can be ramped up in speed if optimized ...

trbarry

27th February 2002, 23:00

Hi Blight -

SimpleResize is mostly assembler with C/C++ code for setup and interface to Avisynth. The code is out there in the same zip, but it currently only handles YUY2. If you use it you could probably quickly port the small amount of C code to Delphi and imbed the assmembler run time loop if Delphi allows this, and accepts the same syntax. I've never used Delphi.

And BTW, SimpleResize doesn't really upsize that well either. That's where BiCubic excels. But except for folks without overlay hardware, who cares? ;)

You are indeed a coding madman if you whupped that together just while waiting for my reply. ;)

But no matter how fast Delphi is by some standards I don't think it can do real time video scaling. That's an assembler job. (or hardware)

- Tom

Blight

28th February 2002, 08:59

I don't really use this code for real-time video. It's for resizing a standard windows bitmap (hbitmap) for a background image while MP3 are playing or for the DVD image when in stop mode.

But I guess my solution is fast enough, it simulates grabbing sub-pixel data using an x4 image size (all simulated, the image isn't actually in there). I'm not sure what the technical name for this approach is. I just like to call it factor scaling. And it's all done in RGB, since windows bitmaps are RGB, converting to YUY2 first isn't really an option.

tg0021

12th March 2002, 10:24

I've just made a try to compare bilinear, bicubic and simpleresize. Your filter is amazing : it's quite as sharp as sharp bicubic and a lot faster than bilinear.

one problem : I got a few green lines on the right of the pictures with simple resize. Of course I could crop a few the right of the pictures but it's not a nice way. Do you know why those lines appeared.

Here is the avs script
LoadPlugin("D:\mpeg2dec.dll")
Mpeg2source("D:\Resize\vob.d2v")
LoadPlugin("D:\SimpleResize.dll")
crop(6,0,705,574)
SimpleResize(544,304)
#Neutral
#BicubicResize(544,304,0,0.5)
#Sharp
#BicubicResize(544,304,0,0.75)
#Bilinear
#BilinearResize(544,304)

hakko504

12th March 2002, 10:30

LoadPlugin("D:\mpeg2dec.dll")
Mpeg2source("D:\Resize\vob.d2v")
LoadPlugin("D:\SimpleResize.dll")
crop(6,0,705,574)
SimpleResize(544,304)
#Neutral
#BicubicResize(544,304,0,0.5)
#Sharp
#BicubicResize(544,304,0,0.75)
#Bilinear
#BilinearResize(544,304)
Never use odd values in crop. Change it to 704 and it should work.

tg0021

12th March 2002, 11:30

it works great w/o odd numbers in the crop. Thanks for the tricks

kythorn

12th March 2002, 18:22

@trbarry:

Out of curiosity, and at the risk of sounding like an idiot: Do you think this resize filter will be useful for resizing what started as a digital satellite capture? Obviously, this isn't true actually a digital capture, but captured via svideo @ 720x480 via huffy (I'm still working on extracting digital streams from my dtivo, but haven't gotten there yet)

There's *is* a fair amount of noise in my satellite feed anyway (DTV's using some hideously low bitrates on a lot of channels lately), and in general I like to use a temporal (not spatial though) smoother on it. This results in a fairly good picture in and of itself, but then any resizing method I've tried so far filters it even MORE and it winds up looking ridiculously oversmoothed/filtered.

I plan on trying this out when I get home later, but as thats a long ways off, I'm interested in your (or anyone else reading this) thoughts on this matter.

trbarry

12th March 2002, 19:40

kythorn -

It should do fine in this case. Good results with SimpleResize depends mostly on 2 things:

1) You already have done all the filtering you want (or will add it later). If you want more then you might be better off with BiLinear or a very soft BiCubic.

2) You are downsizing, or at least not upsizing by very much. To upscale a lot you might want BiCubic.

- Tom

MaTTeR

9th April 2002, 00:47

trbarry,

I got pretty amazing results with both quality and performance. It appears I'm late for the party though :-) Thankfully Acaila pointed me to the dll. My FPS has shot from 27FPS to an average of 36FPS, peaking at 41FPS.

Very nice work though, I'll be using the dll from here out.

Dual PIII 850's
768MB RAM (Highly Tweaked with BXTune)
WinXP Pro

Anyways nothing more than a thank you message and I should also point out great work on the optimization of the XviD DSF:D

You don't have a PayPal acct setup by chance?

trbarry

9th April 2002, 03:19

You don't have a PayPal acct setup by chance?

MaTTeR -

Thank you for you kind comments. I do have a PayPal account, but not for this. Instead please see the section in my ReadMe file ( www.trbarry.com/Readme_SimpleResize.txt ) about 'Philanthropy-Ware'.

That is, make any (totally non-obligatory) donation to the Electronic Frontier Foundation to help fight silliness like the DMCA or the new Disney/Hollings CBDTPA (Conniving Broadband and Digital TV Prevention Act) legislation. But if you do, be sure to tell everyone about it so they do too.

And thank you again for being willing to listen to me rant. ;)

- Tom

trbarry

9th April 2002, 03:28

Since this thread has opened up again I thought I'd mention something.

I've been reading up on it a bit and it looks like I really just re-invented BiLinear Resize, as MMX/SSE/SSE2 code. That is, SimpleResize is more of a standard BiLinear Resize like you might see in the text books.

The BiLinearResize() in Avisynth (and therefore in practically everything else) has a softening filter added to it, but SimpleResize just omits this.

So it could have been called UnFilteredBiLinear(), but I didn't know that at the time. ;)

- Tom

Acaila

9th April 2002, 09:09

Any chance you could make an UnfilteredBicubicResize() as well? :)

I really like this filter's speed (I use it mostly for testing codec and filter settings) and the added quality of bicubic over bilinear would make me switch permanently. VDub's and Avisynth's various BicubicResize filters either blur or sharp too much most of the time.

trbarry

9th April 2002, 15:06

Acaila -

I don't really yet understand the mathematics that evaluates the two parms for sharp/soft in BiCubicResize(). I suspect you can already get the effect you want by varying those. Then use BiCubicResize for upsizing, SimpleResize for downsizing moderate amounts or interlaced, and BiLinearResize for extreme downsizing or noisy material.

But BiCubicResize probably can be made to go faster for the most common case of resizing both horizontal and vertical in YUV color format. This could be done just by keeping the output of the vertical resize in a form that is efficiently used by the horizontal resize. Right now it resizes vertical, converting the output to YUY2 format. Then it horizontal resizes, converting one line at a time to a more convenient work format before resizing. This creates an extra pass through the data and probably slows it down some.

I was actually looking at optimizing the copy of BiCubicResize in DVD2AVI when I decided to write SimpleResize. I probably won't be doing anything on this soon but I do want to also create a set of these resizers that work on YV12 4:2:0 format data. This is the format that is used internally inside DVD2AVI, Divx5, Xvid, and the way data is stored in mpeg2 (DVD's) and mpeg4 (Xvid). It would be nice to avoid all the unneeded color conversions that slow things down and introduce small errors.

But that format wouldn't help Avisynth much except it would allow a resizer in mpeg2dec.dll to go faster.

- Tom

Acaila

9th April 2002, 17:13

Thank you Tom for that elaborate reply. I wasn't aware that avisynth's build-in resizers did their work with colorspace conversions, but it would certainly explain the speed difference between those and your SimpleResize (yours sometimes doubles my encoding speed :) ).

I don't really yet understand the mathematics that evaluates the two parms for sharp/soft in BiCubicResize(). I suspect you can already get the effect you want by varying those.

Probably, except I'm not sure anyone knows what unfiltered would be. I know (0,0.75) sharpens and (0.333,0.333) softens the image, but is unfiltered (0,0.5) or (0,0.6) or some other value or does it always filter it? If someone knows for sure the mathematical unfiltered value please let me know. There still remais the issue of slowness of the existing resizers though....

but I do want to also create a set of these resizers that work on YV12 4:2:0 format data. This is the format that is used internally inside DVD2AVI, Divx5, Xvid, and the way data is stored in mpeg2 (DVD's) and mpeg4 (Xvid).

Did I understand this correctly and will XviD get an internal resizer and will you be working on it?

trbarry

9th April 2002, 21:48

Did I understand this correctly and will XviD get an internal resizer and will you be working on it?

I don't know if they want a resizer built into Xvid. But in looking at the very similar code in DVD2AVI, Xvid, and mpeg2dec I noticed that it would be more efficient to resize in the 4:2:0 color space before converting to the more common YUY2 format that is often passed around. The conversion to YUY2 or RGB is just creating redundant (interpolated) data bytes.

Now Xvid may already be able to pass YV12 format to the display/render filters, I'm not sure. But DVD2AVI and MPEG2DEC both convert it to YUY2 format first. In MPEG2DEC's case that is necessary to pass it to Avisynth but I could still put a version of SimpleResize into it that operated before that happened. For DVD2AVI it may even be possible to resize and pass the YV12 data directly to Xvid for even more performance gains and probably slightly better quality for any material that did not need Avisynth/Vdub filters.

So I probably will look into a YV12 version of SimpleResize. And if I do then I'll probably also put it into DVD2AVI & MPEG2DEC. But keep in mind that I'm always thinking and talking about a lot of things and not all of them ever get done. I'm just tossing out ideas here.

Maybe others can pick up and do some of these.

For instance, a version of BiCubicResize that operated on YV12 format would probably be twice as fast as one for RGB simply because YV12 has half as much data. But that really only works if you resize before you convert to another color format.

- Tom

Acaila

10th April 2002, 11:06

Most of us are using other filters as well before we resize the image. So resizing first probably wouldn't make things much faster because colorspace conversions are still neccessary for further processing, and some other filters work better when used before resizing.
Having other filters operating in YV12 directly in DVD2AVI would certainly help a lot, except we still need Avisynth to feed the data in VDub. If we ever get a program that can encode the movie without using VDub and which handles YV12, all these problems will be solved.
I heard the XviD people are working on a new encoding program because it's needed for B-frame support. If this can be made to read DVD2AVI project files we're settled. Or maybe encoding straight away in DVD2AVI, but unless someone severly upgrades the current version it won't work to satisfaction (wasn't Nic working on that a while back?).

So as far as resize filters go, I believe the best way to make them faster right now is throwing in some optimization code or make it so they work in YUY2 exclusively (if that's possible).