Why are you considering resizing that much?
It is very fast already and contributes only minimally to the whole processing time, even if there are no other filters.

Sure. My motto is 'dumm idea is idea too'... ;)
This is only my idea. It is'nt a 'question of live or death'... :)

Personally I prefer quality-up over speed-up.


Hmmm, i think...

How much is different product of bilinear and bicubic (or another algorithm) for 'little change' of dimension? E.g. resize from 708 to 704 pixels?

No! - We had this discussion some time ago, about combining filters, and IMO we do not need a specialized luma version of every filter. I will not argue if it has a place in XViD, but it doesn't in AviSynth. (V/H)ReduceBy2 are specialized enough resizers, but they are fast enough and general enough to deserve a place.

Besides how many percent of all Avisynth encodes are B/W, wouldn't 5% be a high estimate. How much time would you save? 1-2% of overall time in an MPEG2->MPEG4 conversion? Does it seem worth it to you?

I agree.

Absolutely 100% correct :)

Quote:

I think this would actually lesson cache hits compared to the current scheme as each unpacked line could be created from register values during the vertical resize and immediately horizontal resized (after the line was done) while still possibly in some level cache.

So, when a vertical line is done, it is stored unpacked in the one line tempbuffer, and immediately resized?!? Sound very reasonable speedwise. It does however sound quite complex codewise, but it should be tested, since it could give up to a 50% speed increase (filteredresizeH is slower than V).

The only problem I see is, in the cases where it would be more optimal to resize horizontally before vertically. Now Avisynth chooses the axis on which it preserves the most detail, so the second resizer has the best possible quality to resize from.

98% users use Avisynth for making personal copies of DVD or TV rips ;)

Answer is clear..., don't you think?
The downsize-ratio by width is generally smaller.