DScaler plugins.

[sh0dan]

Just had a look at DScaler source.

It seems to be quite possible to import DScaler filters into AviSynth.

Is this something that could be useful?

DScaler seems to always operate in YUY2 (unfortunately some might say), but there is a good amount of nice filters available - mainly for deinterlacing.

It'll take a fair amount of work to get done, so consider that development on other issues will not be done while this is being implemented.

[hanfrunz]

I think it would be usefull. And it would be usefull, if you could use avisynth-filters in DScaler aswell!

hanfrunz

[scharfis_brain]

Are other Dscaler filters/plugins available than those which are already included in Dscaler?

[WarpEnterprises]

what's DScaler?

[sh0dan]

http://deinterlace.sourceforge.net/about.htm

[Wilbert]

Maybe Tom can give some useful comments, since he writes plugins for it? Myself, I never used it.

[sh0dan]

Well - it's basicly a realtime deinterlacer, with some added postprocessing filters. It seems to allow advanced deinterlacing on capture sources, so you can watch TV on your PC. Also some basic postprocessing (like gamma, tweak) is implemented.

They have a very nice GUI - if only they had based their software on AviSynth ;)

[trbarry]

I use DScaler for all my TV viewing these days. I have a 55" HD RPTV and it is almost necessary to use a deinterlacer on NTSC at that size and resolution so it doesn't look totally awful.

I have not been very active on the DScaler team for a year or two now except for contributing a couple deinterlace filters.

My UnFilter(), GreedyHMA(), and TomsMoComp() filters already share code between Avisynth and DScaler, so it is not really that hard to port. Some of Lindsey Dubb's filters (Peach, etc.) also have a DScaler origin and have been a really valuable addition to our Avisynth tool box.

My only mixed feelings about it that have kept me out of this thread so far is that DScaler runs only in the YUY2 color space and I'm currently doing most everything in YV12. Plus there is a possibility they are going to change the filter architecture for DScaler release 5, though that is still very uncertain and may well not occur.

But the ability to run DScaler filters would still probably be a quite useful function. You would probably want a filter of some sort that took arbitrarily named keyword parms and passed them through somehow if you just wanted to run the same DScaler binaries.

- Tom

[sh0dan]

@trbarry: I agree 100% with your point of view. Two points are holding me back:

1) YUY2 only.
2) Can't really see any filters that doesn't have an AviSynth equivalent. I haven't used DScaler enough to actually know if this is true though - thus this thread.

I'll open a vote for feature priority, when I actually get the time to do them. Right now getting (fast) YV12 filters available has been the top priority, but there are stuff like audio, more efficient caching, bug fixes, conditional filtering and a new smooth filter I have drafted, that also have high priority.

[jamesp]

I'd love to see an Integrated Audio Filter that could do Bass, Middle and Tone Adjustments to the audio instead of dscaler plugins. The avisynth equivalents seem to do a better job anyway.

Jim

[High Speed Dubb]

Yeah, I think most of the important DScaler filters (Tom’s stuff and mine) have already been ported to AVISynth. Probably the most interesting filter that leaves is Sharpness, and there are already lots of AVISynth filters which do similar things.

So the reason for a DScaler Import filter would be for future DScaler filters. But there’s been some discussion of significant changes to the DScaler filter API, and other discussion of changing the whole project’s architecture. So it’s probably better to wait until some new, interesting DScaler filters show up.

[avih]

maybe, the authors of popular audio/video filters related software (vdub/mod, avisynth, dscaler, etc and their respective filters authors) could sit (metaphorically speaking) down together and decide of a common filter api, which would be general enough for both audio and video, non-linear, conditional, shifts, conversions/transformations (including size/frame/sample/etc rates), more than one colorspace, etc, such that apps authors would be able to concentrate on apps, and filters authors would be able to work on filters, and all filters will work with all apps.

if even a common filter invoker lib would be written, then it could be incorporated into all major filter related apps, and each maintainer will be able to focus on the stuff s/he does best.

i think such an initiative would be beneficial to the whole a/v community.

[High Speed Dubb]

There are some speed optimization reasons why real time video display should use a somewhat different architecture than AVISynth.

With certain applications (especially video game input), even a small video time delay is unacceptable, which means some kinds of video processing pipelines are no longer feasible. Normal video is more forgiving, since you can potentially delay the audio to match it.

To optimize the use of memory caches, processing partial frames can be faster than frame by frame. But for certain filters (spatial smoothers / sharpeners / scalers), that can be a pain.

It would be possible for there to be an API which allows for all different sorts of filters, and to have the video application determine which filters can be used for that kind of video. But that could get to be a pretty complicated API, which could discourage anyone from writing filters for it.

[ErMaC]

I would agree that conceptually the idea of a universal filter framework sounds really neat, but in practice it would probably hinder more than it helps. I won't repeat what HiDub said, but I agree with her point.
I think the more productive thing would be to keep the various filter APIs close enough to eachother that porting isn't very complicated. As we've seen there are people who can share the majority of their codebase between these two apps, so their filter APIs can't be that different. That's probably good enough for now.

[Guest]

Originally posted by ErMaC
I won't repeat what HiDub said, but I agree with her point. Previous detective work has established that High Speed Dubb is male. :)

[trbarry]

Probably the most interesting filter that leaves is Sharpness, and there are already lots of AVISynth filters which do similar things.

Lindsey -

Unless there is a new one I don't know about all the DScaler sharpness code is taken from my Greedy(High Motion) plugin and already exists in Avisynth UnFilter(+,+).

- Tom

[High Speed Dubb]

ErMaC,

Yep — What Don said.

Tom,

Oops — Yeah, I remember that, now that you mention it. I guess that leaves some of the faster deinterlacers.

[ErMaC]

Darnit, and here I was thinking I was being all intelligent and considerate by checking the name in the post and using the appropriate gender. :P Guess sometimes it pays to assume everyone's male.

[sh0dan]

Guess sometimes it pays to assume everyone's male.

LOL!

On the other hand it would probably spoil most of the fun a night at the disco. ;)

Anyway - a welldefined "standard" for filters is probably utopia, unless we want to take on either big limitations or make them very complex (in which case it is often easier to simply port them).

Each filter type has it advantages, and drawbacks:

Dscaler: Linear. Speed is a requirement. Nice GUI.

ffdshow: Linear. Speed is a requirement. Linear speed required (for fluid playback).

VDub: Linear. Good GUI interaction. Speed doesn't have to be linear. Quality can take priority over speed. Pretty safe (not many things to take into consideration).

AviSynth: Nonlinear. No GUI interaction. Nonlinear speed ok. Quality over speed is acceptable.


Different input/output pitch is the most common problem to run into when porting to AviSynth. Also the multiple colorspaces are a big factor. AviSynth is the also the only "bottom up" solution, because it is nonlinear. Most other filters pass on frames from the top filter to the bottom filter - AviSynth frames are requested from the last filter.

In conclusion. AviSynth has everything, except linear speed and the GUI functions so many of us miss. It is the most flexible, but also the most complex.