AviSynth 2.5 updates

[sh0dan]

Hi!

Thought we should have a thread for posting updates and additions to the 2.5 core - and where these changes could be discussed.

New changes:
- Rewrote temporalsoften for yv12, using mmx/isse. It is now many times faster than yuy2. The new algorithm will be converted to yuy2 later.
- Implemented simple cache hints for temporalsoften - it breaks on release build, therefore some optimizations has been disabled. Still is slightly buggy though, which can affect temporalsoften.
- Implemented histogram for YV12. It now shows out-of-range values with a slightly yellow color. (this is a nice filter!) It no longer automatically converts to yuy2.
- Changed limiter default upper luma value to 236.

I found out that the internal cache is broken - or at least works very badly - it is not the easiest code to understand (probably an understatement), so my opinion is that it should be completely rewritten - doing so would probably be necessary for 2.5 beta, to have it tested properly.

In general I feel we are very close to 2.5 beta. I would like to have compare and convertfps working for 2.5 beta, but I don't understand the code that well, so it'll take some time.

Edit: Would you kill me, if you had to recompile all plugins for 2.5 beta? :rolleyes:

[Wilbert]

Nice! The documentation is also getting ready. I updated the faq (but it still must be commited). The list of functions on www.avisynth.org is updated (although I need to correct some stuff), but I'm still missing descriptions of ColorYUV, Limiter (I know what this one does), AlignPlanar (is this a public filter ?), FillBorder (is this a public filter ?). Maybe you can come over to www.avisynth.org and add them, so that I can copy them to sourceforge. At last syntax.html needs to be updated.

[sh0dan]

Great!!!

> AlignPlanar (is this a public filter ?), FillBorder (is this a public filter ?)

No, and No - these are only for filters and plugins to use. Shouldn't be necessary for users to worry about.

ColorYUV is pretty easy. Most ranges are 0 to 256 with 0 being default (no change).

We still need info(), converttoyv12(), many audio filter updates, YV12 filters:
* SwapUV(clip) - Swaps chroma channels.
* UToY(clip) Copies chroma U plane to Y plane (image is now half as big)
* VToY(clip) as above, but V plane.
* YToUV(clipU,clipV) - puts the luma channels of the two clips as U and V channels. Image is now twice as big, and luma is 50% grey. Use MergeLuma, if you want to add luma values.

AviSource, Blanclip, (others??) take YV12 parameters.

I'll keep coding until the beta release, and then I'll give you a hand with the docs.

[vinetu]

Hi

A question (may be bug report)

For decode VOBs in YV12 collor format
I use MainConcept MPEG2 Video Decoder (it come with MainConcept MPEG2 Encoder)
as DirectShow filter and a simple avs:

DirectShowSource("D:\temp\test.VOB")

and it work correct with "avisynth_250_a_041102.zip",but all
new versions (including "avisynth_a_071202.zip") shifts
the collor channel 16 pixels to the right horizontaly !

if I use YUY2 DirectShow filter (Elecard MPEG2 decoder v.2.0) all
new versions work correctly,but the target here is YV12 .
What you think - it's an incompatibility between Mainconcept DS filter and new avisynth versions(newest than 04 nov 2002)
or it's a bug ?

Edit: if I post to wrong tread - remove my post from here!

vinetu

[Wilbert]

No, and No - these are only for filters and plugins to use. Shouldn't be necessary for users to worry about.

Ah, that's what I suspected. Thx.

We still need info(), converttoyv12(), many audio filter updates, YV12 filters:
* SwapUV(clip) - Swaps chroma channels.
* UToY(clip) Copies chroma U plane to Y plane (image is now half as big)
* VToY(clip) as above, but V plane.
* YToUV(clipU,clipV) - puts the luma channels of the two clips as U and V channels. Image is now twice as big, and luma is 50% grey. Use MergeLuma, if you want to add luma values.

AviSource, Blanclip, (others??) take YV12 parameters.
I already added all this (not on sourceforge yet).

I'll keep coding until the beta release, and then I'll give you a hand with the docs.
Ok.

[Boulder]

A small bug report from here as well (I don't know if there's an official bug report form somewhere) :

TMPGEnc won't load my script properly if I resize to 336x272 and add 8 pixel borders on each side so that the resolution is a standard PAL VCD 352x288. If I just resize to 352x288, it works fine.

Here's the script I tested:

SegmentedAVISource("c:\temp\captures\capture.avi")
ConvertToYV12
BilinearResize(352,288) #works
#BilinearResize(336,272).Addborders(8,8,8,8) #doesn't work

Both methods do work with VirtualDubMod so I don't know what the issue actually is. I prefer adding the borders to benefit from the TV overscan area.

[sh0dan]

If it works in vdub it is _probably_ not an AviSynth error, but probably a conversion or import filter bug - you should converttorgb24 anyway, since this seems to be the format TMPGenc uses anyway.

[Boulder]

The problem couldn't be solved by colorspace conversion, I also tried keeping the colorspace as YUY2 (the original colorspace) with no luck. CCE2.5 seems to accept the script just fine.

[Wilbert]

Thus the following script:

SegmentedAVISource("c:\temp\captures\capture.avi").ConvertToYV12
BilinearResize(336,272).Addborders(8,8,8,8).ConvertToRGB24

results in the same error? What happens if you remove ConvertToRGB24 from this script, remove xvid.dll and install DivX5. Still the same error?

[Boulder]

Originally posted by Wilbert
Thus the following script:

SegmentedAVISource("c:\temp\captures\capture.avi").ConvertToYV12
BilinearResize(336,272).Addborders(8,8,8,8).ConvertToRGB24

results in the same error? What happens if you remove ConvertToRGB24 from this script, remove xvid.dll and install DivX5. Still the same error?

If I rename xvid.dll to xvid.bak, the script produces an error "Floating decimal point is divided by 0" by TMPGEnc (not in the preview window). I already have DivX5 installed so I suppose it should take over then.

If xvid.dll is not removed, TMPGEnc shows that the clip is 360x56 and 24fps. It can be fixed by correcting the values manually but I think that's just an annoying workaround to the problem;)

It works both ways in VDubMod, however.

[HarryM]

Sh0dan: About audio processing in Avisynth. Can you add into avisynth any function for boosting of audio?
E.g. based on LigH formula or HeadAC3he algorithms.

Similar to 'TFM audio filter'. This is great for listening... :D

[Marc FD]

hi ^^

i'm doing "layer" now.
i've analysed the whole thing and... it needs total rewrite.
i'll macroize the good stuff and add YV12 support.

[Marc FD]

YUY2 stuff cleaned. wow, 340 lines less !

i added Sub/Abs operations, first does like avisynth Subtract() and second was asked by someone to do masks if i remember well.

BTW, i'll need some Layer() fans to check functionnnality in YUY2/RGB32/YV12 when it would be finished.

[ErMaC]

Is there any chance we can get track matte support in Layer? Since YUV doesn't have an Alpha Channel, it'd be nice to be able to supply another AVI clip as an Alpha Channel (i.e. as a track matte) so that we don't need to convert to RGB to make use of Alpha Channels.

[Marc FD]

>Is there any chance we can get track matte support in Layer? Since YUV
>doesn't have an Alpha Channel, it'd be nice to be able to supply another
>AVI clip as an Alpha Channel (i.e. as a track matte) so that we don't
>need to convert to RGB to make use of Alpha Channels.

yes, sho0dan already suggested that, and i'll code it for YV12.
i think i can implement it in YUY2 too. the code will even be shorter, because i'll condensate it even more ^^

BTW, in RGB, you have an alpha channel per pixel. in YV12, you'll have 3 alpha channel for each Y,U or V channels

[ErMaC]

Well, really that's probably unnecessary since you probably don't need to blend the planes different amount. ^_^ I assume you'll allow a single clip to be applied as an alpha channel to all the planes?

[Didée]

Originally posted by Marc FD
...i added Sub/Abs operations, first does like avisynth Subtract() and second was asked by someone to do masks if i remember well.
...
Yep, that was me.
I'm glad you actually remembered my suggestion - and by the time you make something available, I will test as much as I can
(though my situation makes this pretty slow: The fastest possibilities for me are from one day to the next ... no chances for quick reports :( )

[Marc FD]

>Well, really that's probably unnecessary since you probably don't
>need to blend the planes different amount. ^_^ I assume you'll allow a
>single clip to be applied as an alpha channel to all the planes?

it'ld be an external function, like UnifyAlphaYV12, because it wouldn't really be faster to downsample the Y plane internally anyway.

if i add this functionnality, it's because it's easier to code, and almost the same speedwise.

>Yep, that was me.
>I'm glad you actually remembered my suggestion - and by the time you
>make something available, I will test as much as I can
>(though my situation makes this pretty slow: The fastest possibilities
>for me are from one day to the next ... no chances for quick reports )

no problem. if you and ErMaC are okay to test/check what i do, i'll feel better. i never used layer, and first time i tested it ("add" op) after i cleaned the code, i thought it was my fault if the chroma was weird. and it wasn't ^__^

[Boulder]

Originally posted by Boulder
If I rename xvid.dll to xvid.bak, the script produces an error "Floating decimal point is divided by 0" by TMPGEnc (not in the preview window). I already have DivX5 installed so I suppose it should take over then.


I noticed this thing also when trying to load an DivX file. TMPGEnc stated the same error message and when I went to the source range screen, it showed the Avisynth error "Unrecognized exception" which pointed to the line where I resized the clip.

So, if I resize this clip to 336x272 and add 8 pixel borders on each side and get 352x288, it doesn't work in TMPGEnc.

If I resize to 320x544 and add 16 pixel borders on each side and get a CVD resolution, 352x576, it works just fine.

Both do work in VDubMod.

[sh0dan]

OK - I'm back.

I did get to work on some features in the weekend. 2.5 beta is close.

Changes:
* Added: ColorYUV parameter "analyze" can be true or false. This will print out frame color and luma statistics.
* Added: ColorYUV parameter "autowhite" can be true or false. This will automatically adjust U/V offsets for each frame, so that color will be normalized for each frame. This is useful for recorded material, where whitebalance has been set wrong.
* Added ColorYUV parameter: "autogain". This will adjust luma to have maximum luma range for each frame. This function is also known as "autolevels" in some programs. This can be useful for recordings with bad light conditions, but it might make images flicker.
* MMX/ISSE optimized BitBlt function. This gives a reallife performance increase of ~15%.
* Added dissolve YV12. This also corrects FadeIn/Out.
* Separatefields now seems to work.
* MMX optimized YV12 merge functions.


@Marc: How's work going on Layer / Compare / Subtract?

@All: I'll try to catch up with the forum later today.

[frank]

@shodan
Vobsub doesn't work because it is YUY2 format.
But why does Avisynth 2.5 crash when I set it after the ConvertToYUY2 command?

...
ConvertToYUY2
VobSub(...)
return

A bug in ConvertToYUY2?
Any way to use Vobsub in Avisynth 2.5?

[sh0dan]

If Vobsub is an 2.0 filter, it doesn't work with 2.5 - filters are not compatible between these versions

[Boulder]

@frank and sh0dan

See Gabest's answer to my question here:

http://forum.doom9.org/showthread.php?s=&threadid=39204

[Marc FD]

>@Marc: How's work going on Layer / Compare / Subtract?

well, i take my time, but i finished to clean Layer YUY2/RGB32 code, it's about 500-600 lines less long. i'll do YV12 of Layer/Compare this week i think. I already converted Subtract a while ago, and Layer will have the same functionnality (in MMX)

[JohnMK]

btw, you guys are doing something right, because I'm getting between 50-80 fps avg. per pass on my P4 3.06GHz @ 3.34GHz, DivX 5.02 + B-frames, 2-pass.

[sh0dan]

New updated version (internal changes).


* AviSynth now attempts to get handle from AviSynthpluginInit2 when loading plugins.
* "internal.h" can now be left out of plugin development.
* Added license exemption to avisynth.h


What this means is that plugin writers should ASAP change AviSynthPluginInit to AviSynthPluginInit2. Older 2.5 filters will still work for a short transition period, but when AviSynth 2.5 hits beta older plugins will no longer be accepted.

This is to make pre-2.5 versions reject 2.5 plugins, to avoid crashes and user confusion.

The speed increase is good - even better than I dared to hope for - nice to see this :)

[MaTTeR]

sh0dan,

Great work as always! TemporalSoften seems to work very well and is very fast.

I've been fighting an odd problem lately trying to deinterlace or IVTC some movies. It seems when I add a smoother filter such as Flux, C3D or tiya3dd before resizing I get garbage frames after the first one. Putting the filters after the resize line fixes the issue. Using the AVS built-in TemporalSoften before resizing does not cause any problems though:confused: The problem seems to only happen when I rip with D2A NOT using the ForceFilm option(ie. No Field Operation). I've tried using different builds of D2A, cropping in different multiples and various MOD-4 and MOD-8 resolutions. As a last resort I've also tried the last 2 AVS builds(16th and 17th) and am using MPEG2Dec3 0.94.

This doesn't seem to be a filter related problem so I thought I'd throw it out here and see if anyone else is seeing the problem or if I'm doing something silly. Sample script-
mpeg2source("D:\test\fwood.d2v",idct=3)
TomsMoComp(1,5,1)
Lumafilter(-1)
crop(16,4,688,472)
tiya3dd(0,6,6,28)
#FluxSmooth(4,2)
#Convolution3D(0,1,6,3,4,2.6,0)
BicubicResize(496,384,0.333,0.333)
Undot()
Limiter() I commented out the last 2 lines and still seeing the same problem. FWIW, various Decomb settings are giving the same result (garbage frames) as using TomsMoComp. I can post a picture if needed. TIA

[sh0dan]

I've been fighting an odd problem lately trying to deinterlace or IVTC some movies. It seems when I add a smoother filter such as Flux, C3D or tiya3dd before resizing I get garbage frames after the first one.

@Marc FD: Would you check, that you always return a valid frame 0, even if you are requested to deliver frame <0 ???

This could give the problem you describe. (temporal soften actually checks if a (frame<0) is requested).

[SansGrip]

Originally posted by sh0dan
(temporal soften actually checks if a (frame<0) is requested). Should all filters do this? Why would a negative frame number be requested in the first place?

[Marc FD]

>@Marc FD: Would you check, that you always return a valid frame 0, even
>if you are requested to deliver frame <0 ???

all my temporal filters where fixed against this a while ago.
i always check. simply to avoid crashes.

but MPEG2Dec3 doesn't check, _like MPEG2Dec_ , so if a filters asks for a bad frame, results are unpredicable. i'll fix that in v0.95

[trbarry]

It is easy to check for a valid frame number but what do we really want to return if it is bad? Is there a standard guidline?

- Tom

[SansGrip]

Originally posted by trbarry
It is easy to check for a valid frame number but what do we really want to return if it is bad? Just what I was thinking. Such special-case code tends to hide bugs rather than eliminate them.

[sh0dan]

In general I think we should hide errors like this - I know it isn't the best practice, but it'll help a lot of users with bad filters. First/last frames are special cases - I don't think this would hurt. (and it's actually a common error - seems like Flux, C3D or tiya3dd might have the bug.

An easy solution would be for the cache to handle these errors, so that it will automatically map invalid frames to the last valid one - making this the default mode of operation. How does that sound? (I really cannot see any downside to this).

[MaTTeR]

Originally posted by sh0dan
(and it's actually a common error - seems like Flux, C3D or tiya3dd might have the bug. I apologize but I mispoke in my previous post. The latest release build of Convolution3D does NOT give me the garbage frames. FWIW, TemporalCleaner_YV12 does not give garbage frames either.

Many thx for working on this guys!

Edit- No problems with Undot either:)

[trbarry]

An easy solution would be for the cache to handle these errors, so that it will automatically map invalid frames to the last valid one

That might give the simplest and most consistant results, and off hand I don't see any downside.

But what about the general case where my GetFrame() couldn't get a frame for any reason. What is really recommended here? Can I return 0? Or am I supposed to do a ThrowError?

- Tom

[SansGrip]

Originally posted by sh0dan
and it's actually a common error - seems like Flux, C3D or tiya3dd might have the bug. Flux shouldn't:


PVideoFrame f = child->GetFrame(n, env);
assert(f);
if(n == 0 || n == vi.num_frames - 1)
return f;
How does that sound? (I really cannot see any downside to this). Sounds good. The only downside would be that, again, we're only doing it to compensate for one or more filters that are faulty. It could perhaps be on by default but with the option to disable it in the interests of debugging...?

[sh0dan]

@Sansgrip: No, flux shouldn't. I don't know if flux is a temporal filter, but if it is it should ensure that it never requests frames below 0 and above nframes-1.

@trbarry: I would throw an error. Seems only fair enough if you haven't done anything wrong :)

[Guest]

Decomb uses a macro to access GetFrame(). The macro maps all requests below 0 to 0, and all requests above max frame to max frame. That way I do not have to explicitly code these tests everywhere. It also ensures that I can't forget to do it.

[SansGrip]

Originally posted by sh0dan
@Sansgrip: No, flux shouldn't. I don't know if flux is a temporal filter, but if it is it should ensure that it never requests frames below 0 and above nframes-1. It's temporal and spatial. That code I posted should prevent it from accessing out-of-range frames, right?

[Guest]

Originally posted by SansGrip
It's temporal and spatial. That code I posted should prevent it from accessing out-of-range frames, right? If n is out of range, you call GetFrame() with it. Looks wrong to me.

[SansGrip]

Originally posted by neuron2
If n is out of range, you call GetFrame() with it. Looks wrong to me. But I don't try to request a frame < 0 or >= num_frames during my own processing. Admittedly I don't stop another filter from doing that, but that wouldn't be my bug... :D

[Guest]

Originally posted by SansGrip
But I don't try to request a frame < 0 or >= num_frames during my own processing. Admittedly I don't stop another filter from doing that, but that wouldn't be my bug... :D Perhaps, but that isn't demonstrated by the code you posted. :)

[SansGrip]

Originally posted by neuron2
Perhaps, but that isn't demonstrated by the code you posted. :) I thought it was. If I'm doing an immediate return frame; if n == 0 or n == num_frames - 1, then presumably my actual processing code will never request out-of-range frames. Perhaps I should have mentioned that it only ever uses a temporal radius of 1? ;)

Or maybe I'm missing something... :scared:

[Guest]

Originally posted by SansGrip
...presumably... As I said, it isn't demonstrated by the code you posted.

[Guest]

Originally posted by SansGrip
But I don't try to request a frame < 0 or >= num_frames during my own processing. Admittedly I don't stop another filter from doing that, but that wouldn't be my bug... :D If they pass n out of range to you and you pass that along to GetFrame(), it is now your bug, because you could have caught it and did something reasonable with it.

[sh0dan]

To avoid this confusion - making the cache check the ranges would make everyone happy. Donalds solution is of course the most graceful, but putting in the checks, we probably avoid many hard-to-track bugs.

Until now I have personally always seen this as something the source filter should check, but now it isn't.

[MaTTeR]

SansGrip,

FWIW, the problem doesn't occur if I put FluxSmooth after resizing. Also, I noticed the problem doesn't occur if I setup Convolution3D _after_ FluxSmooth but both are inserted before resizing. Soon as I comment out C3D, the garbage frames return(except for first frame).

I can't be certain but I'm only seeing problems on true interlaced sources such as a live concert DVD. Hybrid or progressive material isn't giving me a problem at all so far. Hope this helps a bit.

[SansGrip]

Originally posted by MaTTeR
FWIW, the problem doesn't occur if I put FluxSmooth after resizing. Strange. Well, let's take this over to the Flux thread and we'll try to narrow down the possibilities :).

[sh0dan]

Just a quick note: Added (detailed) ColorYUV description at avisynth.org
I hope most of it is understandable, so you all can enjoy this very useful filter.

[sh0dan]

I have updates the alpha during the day.

Jan. 10. compile features:

* General crashbug fixed due to too old cache code used for compilation.
* Optimized limiter for mod8 resolutions.
* Subtract now works in YV12 mode.
* Added Fliphorizontal.
* FlipVertical now work in all colorspaces.


Other important updates that have happened recently:

* Fixed crashbug in resize.
* Fixed bug in temporalsoften, if any threshold was 0. (KP)
* YUY2 mode now uses the new temporalsoften algorithm. (KP)
* Fixed bug in Mergechannels() (KP)
* Fixed "file not found" crash in AviSource. (RB)
* Tweak now works in YV12 (RB)
* Fixed bug in StackVertical (RB)
* Fixed bug in some non-mod-16 resolutions.

Same place (http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html) as always!

Enjoy!

[Guest]

@sh0dan

How hard would it be at this stage to add UINT32 to class VideoFrame that filters could use to attach hints and other info to a frame?

[Bidoche]

what do you mean by UNINT32 ?

[Guest]

Originally posted by Bidoche
what do you mean by UNINT32 ?

unsigned int FrameUserData;

[Bidoche]

why userdata ?
Are you excepting to use it as a way of communication between filters, or just to mark some interesting properties (like field based and co) ?

[sh0dan]

In principle you could attach custom booleans to videoinfo, but I cannot see how you could do it on a per-frame basis. Adding it to VideoFrame would kill the data as soon as a filter returns a new frame. (NewVideoFrame doesn't have the old frame, but only gets the VideoInfo).

The only way to pass directly between filters would be to create an upward-calling function. (Like GetParity) Requiring a rewrite/filter recompile.

The easiest way would be for you to use env->SetVar(const char* name, const AVSValue& val) and env->GetVar(const char* name). It would require your filters to be mapped linear to each-other, but you could add a frame-number just to be sure that nothing funny is going on.

[Bidoche]

@neuron2

Can you explain/develop exactly what you want/mean ?
I have an API rewrite in progress, maybe I can include it (maybe add a ref to the original video in VideoFrame ?)

[Guest]

Originally posted by Bidoche
@neuron2

Can you explain/develop exactly what you want/mean ?
I have an API rewrite in progress, maybe I can include it (maybe add a ref to the original video in VideoFrame ?) I have two filters in my script, one after the other:

FilterA()
FilterB()

I want A to be able to communicate to B some information about each frame that it passes along. The VideoInfo structure contains a pointer to the frame data. So why couldn't it also contain an info struct or int that could be written by A and read by B?

An example application is Telecide() telling Decimate() that a frame is combed, is film versus video, etc.

[Bidoche]

I guess it can, but it would eat space and not be used often,
maybe some subclassing and polymorphism can do it.

[Guest]

What do you mean by "eat space". An int per frame???

I already do it, but the suggested idea would be much cleaner.

[Bidoche]

I am thinking at something like that :

class PropType {
char dummy; //so sizeof is > 0 (avoid two consecutives have same
address (necessary or not ?) )
public:
PropType() { }
};

//property class, subclass it to add specific info if you need
class Property {
const PropType * prop;
public:
Property(const PropType*_prop) : prop(_prop) { }

bool isType(const PropType* _prop) const { return prop == _prop; }

};

class PropertyList {
virtual const Property ** begin() const = 0;
virtual const Property ** end() const = 0;
};

and in VideoFrame:
virtual const PropertyList* getPropertyList() const ... (default
implementation, return an empty list)

or simpler just:
virtual const Property* getProperty(const PropType* _prop) const { return nullProp; }

[Guest]

I don't have a clue what you're talking about. :(

I'll ask again: why is it so hard to add this line to VideoFrame;

unsigned int UserData;

[sh0dan]

Originally posted by neuron2
I'll ask again: why is it so hard to add this line to VideoFrame;
unsigned int UserData;

Because your filter will in many cases not recieve the same VideoFrame as your previous filter sent, and there is no way of preserving the userdata, except if we do some very nasty hacks. (read above)

[sh0dan]

I'll be doing a 2.5.0 beta release today.

There are still some unresolved issues regarding the cache, but Bidoche's solutions to the problem will break the current filters. If he finds a solution for that it can be in the next beta, but the current implementation stays.

Regarding the rewrite Bidoche is doing - while I think it is a very good idea, it'll require many plugin changes - and we're simply too far in the testing process of 2.5, for this to be included.

[Guest]

Originally posted by sh0dan
Because your filter will in many cases not recieve the same VideoFrame as your previous filter sent, and there is no way of preserving the userdata, except if we do some very nasty hacks. (read above) I didn't understand. :)

How can a filter not receive the frame sent by the preceding filter? Make it simple, please. :)

Obviously, I expect NewVideoFrame() to blank the data, but why would that be a problem?

[sh0dan]

The cache inbetween could copy your data, returning only a copy of the frame.

I think the variable solution will be the safest way to exchange data.

[Guest]

Originally posted by sh0dan
The cache inbetween could copy your data, returning only a copy of the frame.Why would it do that?

I think the variable solution will be the safest way to exchange data. What is the "variable solution" and why would it avoid the problem you describe?

Thank you.

[sh0dan]

>Why would it do that?
To cache frames ;)

>What is the "variable solution" and why would it avoid the problem you describe?

You store your information as an AviSynth variable, and retrieve it later in the filter chain. You just give it a name, and sends the value along. (use the env->SetVar(), env->GetVar())

[Guest]

Is there a desscription anywhere of how the current cache works?

[sh0dan]

There was a long discussion in "implementing cache hints". Basicly it is inserted between all filters, and caches frames. 2.5 was only supposed to have cache-hints so that a filter could better control the cache above itself, but we've found out that a larger rewrite is necessary, since the cache doesn't work as it's supposed to... Rather complex issue I'm afraid :(

[Guest]

OK, thanks.

But when would the cache ever COPY a frame? Either the frame is in the cache, in which case, the data is preserved, or it isn't and the filter has to regenerate it, no? If it regenerates it, then the user data is also regenerated.

When the cache copies a frame, couldn't it also copy the user data?

[sh0dan]

I'll try to add it, to see how it work - maybe it does :)

I'll upload a special version for your testing (and include the new avisynth.h) - However - it still seems like a hack.

[Guest]

@sh0dan

Thanks. Maybe it's a "hack" but it will allow me to improve Decomb without having to hide data in the video. :) So, if it isn't too hard I'd appreciate it.

Oh, BTW, MPEG syntax supports per-frame user data for some very good reasons, so it's not exactly unprecedented. :)

[trbarry]

>What is the "variable solution" and why would it avoid the problem you describe?

You store your information as an AviSynth variable, and retrieve it later in the filter chain. You just give it a name, and sends the value along. (use the env->SetVar(), env->GetVar())

Ha! :devil:

I didn't know I could do that. Does this mean that if I used SetVar() in MPEG2DEC2.dll to create a variable called, say, MPD_Crop_Left that an Avisynth script or macro could get away with saying:

Crop(MP2_Crop_Left, 0, 0, 0)

It would allow me to still use the nice DVD2AVI interactive cropping and resizing setup without actually having to to that cropping and resizing in MPEG2DEC2 before deinterlace. The values would just be passed along to the Avisynth filter.

- Tom

[sh0dan]

@trbarry: Sure you can! Not sure if you have to use global-variable. You must set it, when initializing your filter. Setting it at "GetFrame" will be too late.

@neuron: Sure I'll try it... I'm trying out an alternative to temporalsoften (again). It works better, but I would like to have a scene change detector included.

[Bidoche]

Actually there is a design flaw that make caching harder.
Cache is expected to cache constant VideoFrame, but PVideoFrame is a smart VideoFrame *, not const VideoFrame *...

I say we need a const VideoFrame * to make it cleaner.
Then GetFrame returns a 'smart const VideoFrame *' and if you want to modify it you copy it into a 'smart VideoFrame *' and operator= will copy if necessary...

I already have made the code for that.

@sh0dan

what's the problem with the caching code ?
I expected to get news from you with ICQ but you weren't there...

@neuron2

The reason to just not simply add an int, is we can just made it for you own use, and if others use it too as an int, it will make collisions, that's why I was going after named properties
I am not against adding properties but it must be usable by everyone once and for all and prevent collision.
Neither is it possible to add an int for eveybody who wants to tag properties along or to expect the sharing of one to go well...

[Guest]

Since the limitation is that there is no intervening filter, I don't see collisions as an issue.

See, I want something done, not discussed endlessly and then not implemented. :)

[Kurosu]

What about a function that asks on filter initialization the constant allocation/copy/... of a memory space. This could be done with a structure (I don't intend to be C++ish, and it's already enough hoorible this way) like:


Pseudo code in fact...
class Global var
{
private:
char *FunctionRequester; //Several functions inside a same
// addon can ask allocation
char *Memory; //where the data would be allocated
//maybe another property to allow making chained
// list of this class

public:
<To define> GetMemory() //checks for the requester, plus
// maybe copies the data or give
// the direct pointer to it
int <SetMemory> //Other way around
}

I guess the design can evolve much from it. Or the idea can simply be dropped :)

[Bidoche]

@Kurosu

I don't get your point, if your filter wants memory allocated, why not doing it himself ?

[Kurosu]

The function GetMemory() could be given an argument which is the filter for which the data is asked: it could enable filters to communicate, for instance passing to each other a binary map of the frame for various processing.

If Decimate does a env->GetMemory("Telecide",...), it gets the allocated bloc by Telecide (or nothing if the filter hasn't asked an allocation), preferably by a copy. I think that's what Neuron2 asks, though with only an int.

In fact, Telecide would have to first call a AllocateMemory (setting a private member Size, filling FunctionRequester with "Telecide" and doing a new char Memory[Size]), then SetMemory(char *block) would copy Size bytes from block address to Memory.

[Bidoche]

In this case, he could allocata a shared block a memory in decomb and do the same...
But that won't be very clean...
neuron2 is right here, it should be added somehow in VideoFrame

Edit: Finally I can compile the dll, I will see what I can do

[Kurosu]

@Bidoche

That was more a suggestion in Neuron2's case, as I myself don't see quite the need, except this case:

#The whole saves the computation of 2 edge maps...
BuildEdgeMap(...) #Internal plugin building an edge map available for all plugins
RainbowRemover(...) #Filter that removes some Y/UV aliasing problems in analog captures (mostly on edges)
SpatialSmoother(...) #Filter that would blur/soften the pixels if not on a edge

and so on. But no filter is ready to use such features, so yes we can drop the idea.

[Snollygoster]

I just downloaded the latest version 100103 and I realised that its size is much smaller than the previous I got 291202. When I started encoding the speed looked like YV2 speed and not YV12. Is there something wrong?

[sh0dan]

The dll is just UPX-packed - nothing performancewise has changed.

[Snollygoster]

Originally posted by sh0dan
The dll is just UPX-packed - nothing performancewise has changed.

Thank you.

[Richard Berg]

Cache is expected to cache constant VideoFrame, but PVideoFrame is a smart VideoFrame *, not const VideoFrame *...
I'm glad I'm not the only one who thought this was weird. This is the issue I was getting frustrated at in the other thread when I talked about "cached versions of smart overloads of ref-counted pointers" et al. but never explained very well.

Ideally, the cache would utilize ref-counting in an intelligent way, but the interface provided by PVideoFrame isn't really suited to doing what we need.

Back on topic, I agree with Bidoche & Kurosu that inter-filter communication needs to be handled by the script environment. Requiring plugins to do their own memory management is just asking for weird bugs, akin to removing MakeWriteable() or any other useful superclass abstractions.

The AVSFunction interface actually does provide an arbitrary UserData struct with every function call, but as far as I know nothing uses it. I was thinking of using this to implement filter metadata (argument ranges, author contact info, etc. -- see previous thread), but if we're to design an interfilter API there's no reason it couldn't handle metadata too. My only reservation would be DG's, that discussing this is likely to lead to lots of text and no code :)

Anyway, I'm back, and ready to dive into this stuff as soon as I unpack everything. Dual monitors and a real desk should be a very productive step-up from the presentation monitor + wireless mouse/keyboard I've been stuck with the last several months :devil:

[sh0dan]

Hi Richard, nice to hear that you're back.

I hope you can give Bidoche, the feedback he rightly deserves - I'm not much into C++, so hopefully you'll be able to help out more there.

My proposal for advancing:

Release 2.5.0 beta on sourceforge as soon as Marc gets his filters updated. I'm not releasing a 2.5.0 before it rejects 2.0 plugins.
No further updates to the filter interface. There are far too many filters already for us to do so.
Copy the 2.0 (MAIN) branch into a separate branch.
Copying the current 2.5 to the main branch. THIS will be out development line.
Continue to work on 2.5.x final in the current 2.5 branch.
Development of 3.0, regarding targets, design changes, etc. are begun. Fixes and similar stuff in the 2.5 brach is merged into 3.0, if applicate. Bidoche already have some nice stuff to add for proposal.
Developer discussions are set up - mailing lists? closed forum?


I must say, that I feel this is early to begin 3.0 considerations. I would still like to have issues like caching and memory management improved within the 2.5 framework. It must be possible, and I think this would be possible without having to change filters.

As for 3.0 I think we should think more about what would count more for users in daily usage. I'm thinking about GUI, AVI-wrappers, etc. Simply claiming "completely rewrote AviSynth core" as 3.0 main feature isn't something I think will matter much to most users. "How do we make AviSynth more accessible?" is my primary concern now. We have the features - we lack the ease of use.


btw, I hope you don't mind I took the liberty to go around your fastlib stuff, and implemented a simpler BitBlt. :)

[Richard Berg]

I agree with everything above. At some point you have to bit your tongue and cut off new features for a release, and I think we're at that point for 2.5.0 beta. Browsing Bidoche's reworked avisynth.h, it looks excellent, but I think it's better saved for 3.0 unless it can be integrated (and debugged!) with a lot less effort for both AVS devs and filter authors than it appears...

Setting up mailing lists and FTP space for developers can be done immediately on the new server. Web-based applications are easier (edit: to use, not create), if we prefer -- various forums are easy enough to download, and as mentioned I have a file hosting app in the works.

FastLib can die at this point. The ad-hoc way we handle optimizations seems to work well enough, and the particular idea I was experimenting with (forcing direct cache control via movq) requires too much architectural tweaking and even then doesn't work very well on Intel CPUs.

Moving forward, I think you've got the right idea. Further internal rewrites are necessary in some places (eg cache), but big new usability features are the real future. I've mentioned my own efforts in this regard (with poptones) a couple times, but in all honesty it's been stuck for several months. The beauty of OSS is that we can fill in for each other's downtime -- as you've done marvelously with 2.5, I should add -- so I think it's time I showed my cards and pressed forward. Things I wrote:

interfaces to/from HTTP, using IIS on the server end
interfaces to libjpeg and libpng to allow read/write of compressed still-image formats
internal BMP handler for the same with that format
interface to COM for (limited) IScriptEnvironment access from non-C languages


In addition to a GUI and improved AVI handler, other things I think belong in a 3.0 release:

more powerful scripting. Ideas along these lines: if/then/else structures in addition to the '?' operator, more & better keywords for compositing than loop/animate (suggestions needed), allowing functions to return any AVSValue (e.g. if (MotionDetection(showvectors=false) > threshold_from_GUI) Convolution3D(someparameters) else FluxSmooth(otherparameters)), allowing polymorphic functions...
filter metadata + appropriate GUI hooks. as noted in another thread, this could also provide a mechanism for filters to communicate with each other...perhaps not, now that I think about it though, since metadata should really be fixed at startup
I have to run, everyone else post your wild & wacky ideas

[hakko504]

One quick, and hopefully simple question: Will the new revised 3.0 version of avisynth.h break compatibility with filters compiled for 2.5b?

[Richard Berg]

In its current form, yes -- more so once we add the IScriptEnvironment methods for accessing filter metadata -- though be assured we'll look for ways to minimize the impact. For example, it may be time to split avisynth.h into plugin_interface.h and full_scriptenv_interface.h or similar.

[Bidoche]

Hi Richard, nice to see you again. :)

About my changes, I managed to include and compile a part (PClip subclass of RefCounted, and PClip as a template) and it seems to work.
I committed these to the cvs (as a new branch), but since sourceforge html cvs is down, it won't show (I hope it's not my fault).

Back on topic, I agree with Bidoche & Kurosu that inter-filter communication needs to be handled by the script environment.I thought I was saying just the contrary.
At least for what neuron2 needs, I think more logical to attach a 'volatile' tag to VideoFrame than doing exterior inter-filters communications.
Or maybe adding a method to IClip to return this famous user-data, is there case when it's not the top filter who will need it anyway ?

[sh0dan]

Just committed some rather big changes to temporalsoften. Two new parameters - a better and faster blending algorithm and a scenechange detector.

A new binary is up. Note: This one does not load non-updated plugins!

@Bidoche: No - the ViewCVS is down for maintainence (sp?) - and has been for a while - I very much hope sourceforge gets it up - soon!

[Bidoche]

For example, it may be time to split avisynth.h into plugin_interface.h and full_scriptenv_interface.h or similar.

Already done that in the last version of my changes, made VideoFrame almost totally polymorphic and hided VideoFrameBuffer and other implementations details in a videoframe.h

I just committed my last avisynth.h, in branch struct_mod
I will commit videoframe.h and videoframe.cpp when my current edits will be complete

Edit: Hope I didn't parasited the avisynth2_1, I still trouble getting the way with cvs commands.

[sh0dan]

You also committed to the avisynth2_1 branch, making it uncompilable (avisynth.dll - 552 error(s), 73 warning(s)). could you revert this, or fix it?

I don't know if you have to go back to 1.3.2.24 to fix it.

[Bidoche]

Damn I knew something was weird :'(
Will see what I can do
Should remove 1.3.2.26, it was made by my committing, but how does I do that...

Edit: should be restored.

[seewen]

How can we know if the plugins for 2.5 alpha that we owns, are ok with the "InitPlugin2" ?

Or the only way to know that, is to try to use them, and see that it's impossible ;) ?

[sh0dan]

@seewen: Check out this thread. (http://forum.doom9.org/showthread.php?s=&threadid=42871) Otherwise just do a binary search for "Init2" in the dll's. If it isn't there, it isn't updated.

[seewen]

Originally posted by sh0dan
@seewen: Check out this thread. (http://forum.doom9.org/showthread.php?s=&threadid=42871) Otherwise just do a binary search for "Init2" in the dll's. If it isn't there, it isn't updated.

Ok, thank you very much

[trbarry]

I haven't released any of mine yet but I'm putting a PluginInit2 comment under the Special Build Description in the version properties. So you can right click on the dll and check the version info.

- Tom

[sh0dan]

Recent updates:
* AviSynth now NO LONGER READS OUTDATED PLUGINS. Older binary still available.
* Added optional "mode=2" parameter to TemporalSoften. It has a new and better way of blending frames, and provides better quality. It is also much faster. "mode=1" is default operation, and works as always.
* Added "scenechange=n" parameter to TemporalSoften. Using this parameter will avoid blending across scene changes. 'n' defines the maximum average pixel change between frames. Good values for 'n' are between 5 and 30. Requires ISSE, and still untested on YUY2 images.
* Fixed potential crash/corruption bug in temporalsoften, if pitches would change between images.
* Amplify and AmplifyDB now takes any number of volumes, to support multiple channels.
* Added AssumeSampleRate (from 2.0x branch).
* MonoToStereo now maps to MergeChannels()
* Fixed color bug in Tweak. Output of tweak is now within YUV limits.
* Temporalsoften: Fixed chroma-bleeding across scene changes
* Temporalsoften: Cleanup and minor changes.
* Fixed wrong chroma offset in YV12 directshowsource
* Fixed crashbug in resize.
* General crashbug fixed due to too old cache code used for compilation.
* Optimized limiter for mod8 resolutions.
* Subtract now works in YV12 mode.
* Added Fliphorizontal.
* FlipVertical now work in all colorspaces.



You should really try temporalsoften(3,10,10,scenechange=10,mode=2)

[HarryM]

@Shodan:

Hi,

I found (maybe) bug in SceneChange feature at TemporalSoften (build 18012003)!

I use this AVS script:

#LoadPlugin("C:\Program Files\Avisynth2\plugins25\Convolution3DYV12.dll")
#LoadPlugin("C:\Program Files\Avisynth2\plugins25\MPEG2Dec3_094.dll")
LoadPlugin("C:\Program Files\Avisynth2\plugins25\MPEGDecoder.dll")
#mpeg2source("c:\dvd\Oceans11\oceans11.d2v")
MpegSource("c:\dvd\Oceans11\oceans11.d2v")
Crop(6,78,-4,-78)
TemporalSoften(2,5,7, mode=2, scenechange=5)
#Convolution3d(preset="movieLQ")
#Convolution3d(preset="movieHQ")
BicubicResize(576,240,0,0.5)


My sample with bug (xvid- 0.5 MB).
http://sgfan.ic.cz/download/sample.avi

This bug duplicates frames(?). Compare frame 66 vs frame 136 (this frames are identical).
If I dont use scenechange, all is O.K.

Thanks for you work. Avisynth 2.5 is wonderful. :rolleyes:

[wunschkind]

hi,

sorry for this question, but i try to run the new testbinary from 01.18.2003 with mpeg2dec3_94.dll and i get an error message: this isn´t an avisynth 2.5 plugin.....

is there one compiled mpeg2dec for the testbinary or is something wrong here. with the version from 01.10.2003 everything works fine....

i hope you can help a beginner....

thank you

wunschkind

[trbarry]

The following now have AvisynthPluginInit2 (and say so in the Special Build Description in Version Info):

www.trbarry.com/TomsMoComp.zip
www.trbarry.com/UnFilter.zip
www.trbarry.com/UnDot.zip

My DctFilter does not have AvisynthPluginInit2. SansGrip has made an improved version somewhere that also supports YUY2 however it requires VS7 to build, which I don't have.

@SansGrip - does yours have Init2?

The following filters don't have any support for YV12 or the 2.5 alpha yet:

GreedyHMA (I could make a YUY2 only, but won't have YV12 soon)
SimpleResize (YV12 coded but still busted)
STMedianFilter (soon)
MPEG2DEC2 (currently I'm just using Marc's MPEG2DEC3. Not sure of my plans here but this isn't really mine anyway)

Did I forget any?

- Tom

[sh0dan]

Originally posted by wunschkind
hi,

sorry for this question, but i try to run the new testbinary from 01.18.2003 with mpeg2dec3_94.dll and i get an error message: this isn´t an avisynth 2.5 plugin.....


Marc hasn't updated his filter yet IFAIK, so you have to wait for him to relase it, or use MPEG2DEC2, or MPEGDECODER.

[wunschkind]

thank you sh0dan....

wunschkind

[Guest]

Attached is a recompile of Marc's mpeg2dec3_094 that will work with the new Avisynth binary. This is just a convenience stopgap until Marc releases it officially. Hope he doesn't mind.

[Marc FD]

thx don, i was too busy myself to do it ^^

but it's okay now, i've finished all that i wanted to code, i'll have some time to finalize (old) and release (new) filters ^^

[sh0dan]

Great, guys. I'll collect all the updated filters and release a "filter pack" on the SourceForge page, that contains all updated plugins and documentation. Unless somebody minds, of course.

@marc: Are you updating tiya3d?

[Marc FD]

>Great, guys. I'll collect all the updated filters and release a "filter
>pack" on the SourceForge page, that contains all updated plugins and
>documentation. Unless somebody minds, of course.

keep just a link to my site, please.

>@marc: Are you updating tiya3d?

mhh, search about Deen ;)

[vlad59]

Originally posted by sh0dan
Great, guys. I'll collect all the updated filters and release a "filter pack" on the SourceForge page, that contains all updated plugins and documentation. Unless somebody minds, of course.


No problem with me ;)

[Guest]

Originally posted by sh0dan
I'll collect all the updated filters and release a "filter pack" on the SourceForge page, that contains all updated plugins and documentation. Unless somebody minds, of course.
Before I know if I mind, can you please tell me whether you intend to keep the pack updated with new versions on a timely basis? Thank you.

[AmiRage]

Originally posted by trbarry
The following now have AvisynthPluginInit2 (and say so in the Special Build Description in Version Info):

www.trbarry.com/TomsMoComp.zip

Thanks, but now I'm getting an "Avisynth: caught an access violation at 0x00b1131e, attempting to read from 0x10101014" error when using TomsMoComp?!

Any idea? Someone else experiencing the same?

[trbarry]

Thanks, but now I'm getting an "Avisynth: caught an access violation at 0x00b1131e, attempting to read from 0x10101014" error when using TomsMoComp?!

Well, that certainly sucks. ;)

Except for comments, I only changed one keystroke.

But why don't you start a separate thread on it somewhere here. Be sure to mention your equipment (esp. CPU), type of source, and post your script.

That way in case there are others we don't have to hijack this thread.

- Tom

[ARDA]

@Shodan
I was making some tests and the following script shows a bug in Mergeluma for YV12 (Avisynth_180103).
I've tested in two machines (P4 and Athlon 1.4).
#
LoadPlugin("C:\Virtualdubmpg2\Copia de VirtualDubMod_1_4_13_1\MPEGDecoder.dll")
Clip0=MPEGSource("D:\VIDOCQ_SCN\VIDEO_TS\pista1vidocq.d2v").Crop(16,12,696,548).
\BilinearResize(640,352)
Clip1=Tweak(Clip0,bright=100)
Clip2=Mergeluma(Clip1,Clip0,0.5)
return Clip2
# It shows a darker vertical column on the left from second line onwards
It seems to me you should change of mmx_weigh_yv12:

mov esi,[p1]
mov edi,[p2]
xor eax, eax
testloop:
cmp ebx, eax
jl outloop //line 702 merge.cpp it should be .... jle outloop
punpcklbw mm0,[esi+eax]
................

I hope it can be useful
Arda

[Si]

(by neuron2) Before I know if I mind, can you please tell me whether you intend to keep the pack updated with new versions on a timely basis? Thank you.

This is the "problem" I see as well.

If a plugin author wants to publish plugins centrally - then its really good for them to have a place to publish.

But if a plugin author wants to direct people to their site (to keep control or boost their traffic or whatever their reasons) then they should be free to just have a link to their site published as per the current Wiki information.

On a separate issue how could a plugin get voted into being incorporated into the core. e.g. I wrote ViewFields because of a perceived difficiency in Avisynth on my part. I'm no great software writer (just a good critic - ask neuron2 ;) ) and would be more than happy for a superfast version to be added to the core but how can this be achieved.

I'm using Viewfields as an example only - I don't think Avisynth will really lose out if it stays as a plugin :p

regards
Simon
PS when is 2.5 going beta so us mouse types can join in the fun :)

[trbarry]

Because of the update problem I'd sorta prefer that you just collect links right now.

I've got a couple things out there that may change and it's nice to be able to do damage control by quickly replacing a file.

- Tom

[SansGrip]

Originally posted by trbarry
@SansGrip - does yours have Init2? Erm, nope. I'll add it to my list of filters to update :).

[drebel]

@trBarry
Latest links collection,same problem as AmiRage: an avisynth violation ONLY when using TomsMoComp latest with avisynth 2.5a(10.01.03 AND latest test version 18.01.03).Everything back to normal with previous builds...
The script:


LoadPlugin("F:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("F:\PROGRA~1\GORDIA~1\Undot.dll")
LoadPlugin("F:\PROGRA~1\GORDIA~1\Unfilter.dll")
LoadPlugin("F:\PROGRA~1\GORDIA~1\TomsMoComp.dll")
LoadPlugin("F:\PROGRA~1\GORDIA~1\FluxSmooth-2.5.dll")
mpeg2source("F:\Xfiles3\x3.d2v",cpu2="ooooxx")
crop(6,2,708,572)
TomsMoComp(1,5,1)
Lumafilter(-3,1)
Undot()
LanczosResize(672,496)
FluxSmooth(9,2)
Unfilter(5,5)

Duron @933,win2ksp3,wmpclassic...
A copy - paste prob maybe?

regards,
george

Ps:sorry,but i think its just a minor prob;no real need to start a new thread just for this

[MaTTeR]

Tom,

FWIW- YUY2/Pre 2.5 build works fine but haven't tested the 2.5a build yet.

[trbarry]

Ps:sorry,but i think its just a minor prob;no real need to start a new thread just for this

drebel -

It appears to crash for everyone that uses it besides me. What would qualify as a non-minor problem? ;)

You must be a very patient person.

The problem is that I've got the real TomsMoComp completely torn apart adding 60 fps support. So to make this Plugin2 thing I basically just downloaded my own source to make the change. All I did was add the "2" and changed the release comments. I've got the wierd deja vu feeling that I've been here before too, shipping the same darn release last time. Like something about compile options or libraries or something. But I just can't quite remember.

(winnie pooh repeatedly slaps head)

- Tom

[sh0dan]

Well, it seems like the filter is somehow trying to use image data as a pointer. 0x10101610 is typical Y or U-data (0x10 being black). It could be caused by compiler optimizations - or a simple code error.

@ARDA: Thanks for the fix - I'll commit it ASAP.

[drebel]

-trbarry

you see...it was just a minor problem after all :D
BTW,what's this 60 fps support?Changing to previous build until next generation comes(eventhough it throws blocks to very high motion scenes with (1,5,1)

george

[trbarry]

On my TomsMoComp deja vu crash problem I think I may have this problem (http://forum.doom9.org/showthread.php?s=&threadid=37915&perpage=20&pagenumber=2) again.

If so I should be able to put out a new version this afternoon.

- Tom

[ARDA]

@Shodan
Sorry to bother you again but I think you can change
from lines 722 to 728 merge.cpp :

packssdw mm2,mm2 // double words to words
packssdw mm3,mm3
packuswb mm2,mm2 // words to bytes
packuswb mm3,mm3
psrlq mm2,48 // Align final pixels
psllq mm3,16
por mm2,mm3


for:

pxor mm6,mm6
packssdw mm2,mm3
packuswb mm2,mm6

I've just done a few tests; and probably you'll have
to pair them again, but it seems to me that we obtain
the same final clip and it's a little bit faster.

As always I hope this can be useful
Arda

[sh0dan]

Pairing isn't the biggest issue - the multiplier stall is worse - the function is memory limited anyway - thanks for the snip - I'll test it out :)

btw, mm6 is already cleared, so the pxor is redundant. I also made the y-loop in assembler - I cannot test right now (currently encoding), but I'll do it ASAP.

[sh0dan]

New binary:

* Optimized, and fixed off-by-one bug in YV12 merge (thanks ARDA)
* MakeWriable ALWAYS copy the frame - we still have problems, but they are fixed for now (this is a workaround - we should find out what's causing it).
* BitBlt now throws an error, if called with invalid parameters. (to help debugging).
* Fixed crash in Blankclip on YV12 sources
* NewVideoFrame now checks if the pixel type is valid.
* Blankclip no longer marks the created video as being interlaced.
* NewVideoFrame now throws an error, if a filter attempts to create an YUY2 frame with non-mod2 width.
* Last alpha version!

[Selur]

Last alpha version!
:D HAR HAR :D

Cu Selur

[sh0dan]

:confused: - a sudden strike of insanity?

The 2.5.0 beta is ready. I'll just wait a day and see if there are any major f*ckups in the current version, and then release it along with a 2.5 filter pack. So test away!

[hakko504]

Originally posted by sh0dan
New binary:
* NewVideoFrame now throws an error, if a filter attempts to create an YUY2 frame with non-mod2 width.
Two questions: is this true for YV12 also? Does this mean that a script like below will not retun a clip, but an error message for the user?Mpeg2Source(Pal.d2v)
Crop(5,3,711,561)
BilinarResize(640,480)

[sh0dan]

No - crop adjusts the parameters instead of throwing an error. It's purely internal, and really shouldn't be seen except on buggy filters.

Should crop/resize throw an error on invalid parameters?

[hakko504]

Originally posted by sh0dan
Should crop/resize throw an error on invalid parameters? I think so, yes.

[sh0dan]

Anyone who DOESN'T think so, should speak up - now!!

Edit: Silent update. Both binaries are updated to throw an error.

[Chibi Jasmin]

I DO think, it should throw an error...just to reinforce :D

[WarpEnterprises]

:mad: that way I will never catch up with the doc...

But YES, silent rounding isn't good, e.g. you can't use variables for your image dimensions because they would give wrong results.

Could you please give a deadline for beta release?

[Selur]

"a sudden strike of insanity?"
Just the happiness of a tortured soul, which didn't expect such a fast developement :D
(everywhere is a new version of this and that these days, kind of cool :) )

Cu Selur

[Bidoche]

Personally I would say it should.
correcting parameters without the user knowing can be troublesome

[trbarry]

Sorry for the delay. I only just NOW updated the Avisynth 2.5 alpha version with TomsMoComp v 0.0.1.5 to correct the crash bug.

www.trbarry.com/TomsMoComp.zip

So for anyone running Avisynth 2.5a make sure to right click on TomsMoComp.dll and check the version says 0.0.1.5. Accept no substitutes (they crash). ;)

And a note to any developers. If you compile this there is indeed a problem that it can not be compiled with optimizations (or at least auto-inlining?) turned on. It makes little difference since it does everything in assembly anyway. I have no idea of the reason, maybe optimization turns on fast call or something but I'll figure it out someday. I just turned it off.

- Tom

[trbarry]

I also just updated SimpleResize for YV12 & YUY2 support with pluginit2.

www.trbarry.com/SimpleResize.zip (both old and new versions & src)

I did some optimizations for YV12 so it should run fairly fast (esp. on P4's but others too). This was partly to annoy Marc FD into coming back and doing some more programming for us. ;)

- Tom

[Shootist]

Hi,

I wondered whether there is already a subtitle support for avisynth2.5. On the website (http://cultact-server.novi.dk/kpo/avisynth/avisynth_alpha.html) is a list of working filters
Filters that works with YV12:

Crop, Addborders , ConvertToYUY2, All audio filters, Levels, HSIAdjust, ShowFrameNumber, ShowSMPTE, Subtitle , DoubleWeave, Letterbox, StackVertical, StackHorizontal, VerticalReduceBy2, Greyscale, Resize (all), MergeLuma, MergeChroma, HorizontalReduceBy2, ReduceBy2, Blankclip, Dissolve, FadeIn/FadeOut, Subtract

I asked Gabest in this thread (http://forum.doom9.org/showthread.php?s=&postid=246304) but he didn`t know anything...

[hakko504]

According to AviSynth.org (http://www.avisynth.org/index.php?page=Subtitle) Subtitle is a command for adding One single line of text to the clip, and is not very practical to use for subtitling of a whole clip. It is very useful though to put copyright and other informational texts at the screen in the beginning or end of a clip.

[Shootist]

thanks, I didn`t know it

[trbarry]

I just put out a new STMedianFilter for Avisynth 2.5a.

It supports YV12 or YUY2, uses pluginit2, and hopefully also fixes the purple hue problem. (no longer filters chroma)

The usage and parms are slightly different so be sure to check the readme file in the zip. ( www.trbarry.com/Readme_STMedianFilter.txt )

www.trbarry.com/STMedianFilter.zip (dll & src, old and new vers)

- Tom

[scmccarthy]

@tom

Does the old filter have the purple hue problem? or was it a YV12 problem? I intend to investigate ways to deal with the chroma planes. It alarms me to hear that YV12 is harder to program for than YUY2. There have to be simple programming techmiques we all can learn for planar color spaces.

Although I just realized what the problem might be today; you run out of registers trying to juggle six pointers at once(three for input, three for output), don't you?

Stephen

[trbarry]

Stephen -

The old filter is the one that has the problem. It is YUY2 only and I never previously made an Avisynth 2.5a version of it.

I didn't really solve the purple problem in the new filter. I just stopped filtering chroma. ;)

And most if not all of my filters can work on one plane at a time in YV12 so the coding is actually simpler, plus faster. It is mostly the ones that have to do simultaneous logic on 3 planes that run out of regs.

But things like STMedianFilter do one plane at a time, and in this case I just copy the chroma planes after I'm done with the luma. That was also true for UnFilter. I'll bet that many filters can either do the same thing to the chroma planes as luma or just leave them alone and copy them.

- Tom

[scmccarthy]

@tom

In Fieldcopy()you use memcpy() to copy one row at a time.
Do you know you can use BltBit() to copy a plane at a time, or do you feel that memcpy is faster?

Stephen

[trbarry]

It was probably carried over from something else I had.

Is it faster with BltBit()?

- Tom (answering question with question)

[sh0dan]

When dealing with more than one line, definately - when dealing with a single line - maybe - the call overhead may just null that slight difference out.

A further optimization would be for you to use the _source_ if you plan to futher use it, since it will be in cache. The destination will not be in cache. (Using cache-bypassing movqnt).

I think I'll try to implement "forced prefetching" and see if that gives a notable performance enhancement. The algorithm now gives ~5-10% performance increase when using a set of simple filters. (I don't like artificial test-setups - they might be misleading, as I suspect Richards fastlib tests were (copying to and from the same memory locations is just not real life).

[jang0]

When can we expect to see the beta released?

i'm just curious because you said it's almost finished. don't want to rush you though :rolleyes:

[sh0dan]

It's ready, but I'm going away for the weekend, and I'd like to be around, when it hits the street. Monday or Tuesday is a realistic date.

Furthermore there is some great things being to the documentation, so you aren't missing anything :)

[ARDA]

Tom:"Is it faster with BltBit()?"
Shodan:"When dealing with more than one line, definately ..."

I ask "Aren't we in time for an optimized SSE2 option of BltBit()?"


Thanks Arda

[scmccarthy]

@tom

Tom:"Is it faster with BltBit()?" That's right, I'm the one who asked sh0dan in the first place.

It came up when I substituted BltBit for memcpy while adapting siwalter's ViewFields() for AVS2.5. Just not having to include memory.h was enough of a reason for me. That and BltBit has a reputaion for being fast.

It takes all the same parameters as memcpy (maybe not in the same order), plus its last parameter is the number of lines it needs to copy. So, in all your filters, whenever you don't process the choma planes, you can call it only once per plane, rather than putting memcpy in a loop, copying one line at a time.

Most importantly, as BltBit continues to be optimized, your filters would improve without changing them. It is unlikely memcpy will ever be further optimized.

Stephen

[sh0dan]

Originally posted by ARDA
Tom:"Is it faster with BltBit()?"
Shodan:"When dealing with more than one line, definately ..."

I ask "Aren't we in time for an optimized SSE2 option of BltBit()?"
Thanks Arda

If you have a P4, writes and test it (also performancewise) - I'll be happy to plug it in.

[ARDA]

I don't know if I dare .Maybe Tom can help with that.
But if I have time and "with a little help from my friends"...
I have a P4; but my skills with SSE2 and memory alignment are......

Arda

[trbarry]

"I don't know if I dare .Maybe Tom can help with that."

I'll take a look at that and see if there's anything quick & easy. Somehow I thought that had already been done. I'm sure it was discussed before.

And I think memcopy is already very optimized also. Somebody on the DScaler list was benchmarking it about a year ago and referring to Intel studies on SSE & SSE2 block copy.

- Tom

[Steady]

I was looking at the source for asm_BitBlt (in avisynth.cpp). I believe I can make the SSE version much faster. As it is, it is optimized for CPU/cache when it needs to be memory optimized. Would you like me to give it a shot ?

[scmccarthy]

@steady

Oh yes, don't you think it is a good challenge to see it you can make it faster than memcpy even for a sinlge line? A lot of filters don't process all the planes. Mmmm, I have to get back to programmig myself. Bye.

Stephen

[sh0dan]

Originally posted by Steady
I was looking at the source for asm_BitBlt (in avisynth.cpp). I believe I can make the SSE version much faster. As it is, it is optimized for CPU/cache when it needs to be memory optimized. Would you like me to give it a shot ?

What do you mean?

Prefetching can be optimized, by reading every 64 byte in a line before it is actually copied. Another issue is 8-byte alignment. In 95% of all cases all memory accesses will be aligned, because all new frames are aligned to a 16 byte boundary. But there are some cases where there is a chance of misaligned memory reads. That's the optimizations I see (from AMD's recommondations)

http://cdrom.amd.com/devconn/events/gdc_2002_amd.pdf and the AMD Optimizations guide.

[trbarry]

Prefetching can be optimized, by reading every 64 byte in a line before it is actually copied. Another issue is 8-byte alignment.

There is a point of diminishing returns on this which I think is reached sooner on Intel processors than AMD. Once you fill the very top level cache then I think it can be slower to prefetch more lines. So it's very processor dependent.

But I don't know where this point is. But on my P4 when trying to first optimize SimpleResize it didn't seem to help after the first couple.

Does anybody know how VS6 library function determine what processor they are running on. For instance, does a different memcpy get installed on a P4 system or is memcpy imbedded into Avisynth.

- Tom

[scmccarthy]

does a different memcpy get installed on a P4 system or is memcpy imbedded into Avisynth. Neither, you include the definition in string.h. For Fieldcopy() to use BitBlt(), Fieldcopy() would need an IScriptEnvironment parameter env, so the functions real name is env->BitBlt().

memcpy is part of the standard c library and I do not know if there are different versions for different cpus. I thought the problem with using library functions is they tend to be optimized for the lowest common denominator. Am I wrong?

Stephen

[Steady]

Originally posted by sh0dan
Prefetching can be optimized, by reading every 64 byte in a line before it is actually copied. Another issue is 8-byte alignment. In 95% of all cases all memory accesses will be aligned, because all new frames are aligned to a 16 byte boundary. But there are some cases where there is a chance of misaligned memory reads. That's the optimizations I see (from AMD's recommondations)

That is basically what I had in mind. I remember from writing yuy2/RGB <-> YUV444 conversion that it is much faster. First you burst read from memory->cache, then burst write from cache to memory. It looks slower from a CPU point of view but is actually much faster for the memory because all reads/writes are sequential blocks.
Pseudo code:
//read one byte per cache line
//prefetch can be ignored - mov can not
loop_read:
mov al,[esi]
add esi,64
jxx loop_read
//burst from cache to DRAM
loop_write:
movq mm0,[esi+edx]
movntq [edi+edx],mm0
add edx,8
cmp edx,ebx
jb loop_write
Ideally you would read/write in 4K aligned blocks (a DRAM page). That would be to much trouble in this case. I believe the P4 L1 cache is about 8K ? So if you read/write 1 row at a time it should always be less than this.

One problem with this method is L2 cache pollution since mov al,[edi] will go into both caches.

[Belgabor]

@sh0dan: To remember you of what we discussed once at the very start of 2.5 I posted a present for you on your SF patch trcker :p

[Steady]

By the way ...

I loaded the 1/11/2003 avisynth 2.5 source into VC6 and was totally shocked when it compiled with no errors !

[trbarry]

memcpy is part of the standard c library and I do not know if there are different versions for different cpus. I thought the problem with using library functions is they tend to be optimized for the lowest common denominator. Am I wrong?

Stephen -

No. I am wrong.

I don't know where I was getting the idea that VS6 was already pointing to cpu specific optimized library functions.

I just traced it through with STMedianFilter and (at least in debug mode) memcpy() is just doing a rep movsd loop. So I definitely should be using bitblt.

- Tom

[cweb]

I hope we get the updated Blockbuster plugin :) It's still not calling
PluginInit2.. :)

@Sansgrip, I'm not rushing you, well perhaps reminding
you :p so I hope you don't mind!


Originally posted by sh0dan
It's ready, but I'm going away for the weekend, and I'd like to be around, when it hits the street. Monday or Tuesday is a realistic date.

Furthermore there is some great things being to the documentation, so you aren't missing anything :)

[scmccarthy]

@tom

I don't know where I was getting the idea that VS6 was already pointing to cpu specific optimized library functions. I just traced it through with STMedianFilter and (at least in debug mode) memcpy() is just doing a rep movsd loop. So I definitely should be using bitblt. Two observations:

1) you probably don't need Fieldcopy anymore, since BitBlt is called only once per Fieldcopy call. That is unless calling a separate function helps to clear the registers.

2) Library functions only guarantee functionality, not implemantation. It could be optimized for some compilers and not in others. Classically library functions are considered dangerous if you care at all about optimization. Personally, I don't like writing code that includes stdio.h, string.h, malloc.h, etc., because then I feel like I didn't really write it all. For instance, you can easily write you own rep movsd loop, so why rely on mempcpy for that, you know? A true optimization guru would try the c lib functions however, and then write his own and go with whichever one is faster. So I am not knocking them, just saying that if you rely on them, your no longer personally in control of every aspect of your program.

Stephen

[trbarry]

Stephen -

Well, if you really want to know ...

Fieldcopy is a modified copy of something from GreedyHMA (my first Avisynth filter), which was an Avisynth port from DScaler's Greedy (High Motion) filter, which called a replacement for memcpy via pointer, which was indeed optimized for different processors.

And DScaler itself started mostly as a port from MultiDec.

Thus doth legacy code get created. ;)

Most of the existing code in the world grew something like this. We are all lazy and also know that sometimes it has a better chance of working if it was already working somewhere else.

- Tom

[ARDA]

quote:
--------------------------------------------------------------------------------
So I definitely should be using bitblt
--------------------------------------------------------------------------------
@trbarry
I've been trying to implement it but I've found that dstp is never 16 aligned
so I couldn't make use of "movntdq"; besides that it is not too different of what
Shodan wrote for ISSE.
And as I don't know how to solve that I was expecting news from you. Any?

Thanks in advance Arda

[trbarry]

arda -

I haven't even looked at it yet and won't today as I have some folks coming over to watch the SuperBow on HDTV. But I'm glad someone is working on it.

It's been my own experience that P4's only give a SSE2 performance advantage on 16 byte aligned data. I'd start off checking that it was aligned and just not bothering when it wasn't. For a whole frame of course both the input, output, and both pitches would have to be 16 byte multiples so subsequent lines were also aligned. It's too bad all lines of chroma planes aren't guaranteed 16 byte alignment but at least the larger luma planes all should be.

After that of course you could add code to do the spare change at the front separately and then do the aligned data more rapidly, starting on the 1st 16 byte boundary.

IIRC, in SimpleResize I just OR'd the input ptr, output ptr, and both pitches, then AND'd 0x0f. If the result was not zero I skipped the whole P4 section for that plane, or at least row.

Sorry I don't have time to do more with this today. But I'd be glad to answer any questions that come up if I could be any help.

You can email me at:

trbarry#trbarry.com (#=@)

- Tom

PS - I know DScaler's got its own P4 SSE2 memcopy in it of some sort. You might borrow that, it's GPL on SourceForge. I don't think it is extremely elaborate.

[ARDA]

quote:
--------------------------------------------------------------------------------
It's too bad all lines of chroma planes aren't guaranteed 16 byte alignment
but at least the larger luma planes all should be.
After that of course you could add code to do the spare change at the front
separately and then do the aligned data more rapidly, starting on the 1st 16 byte
boundary.
--------------------------------------------------------------------------------
I'll ask Shodan if it is possible to get a guarante 16 byte alignment for
every plane that would help for anyone who wanted to add SSE2 optimization to a
plugin. Anyway I'll take your advices and see what I can do.

I hope you all enjoy the SuperBow !

thanks Arda

[trbarry]

I'll ask Shodan if it is possible to get a guarante 16 byte alignment forevery plane that would help for anyone who wanted to add SSE2 optimization to a plugin. Anyway I'll take your advices and see what I can do.

I already tried that earlier. Didn't work. ;)

- Tom

[Richard Berg]

I thought we changed that a long time ago? Perhaps the lack of alignment is only affecting YV12?

[ookzDVD]

@Sh0dan,

Your latest Avisynth 2.5 Alpha, build 210103, 2:51PM,
limit the crop for YV12 which should be even number ?

Thank you.

[scmccarthy]

@Richard Berg

I believe the problem is when the Y plane is 16 mod, the choma planes are only 8 mod.

Stephen

[Steady]

Here is an early version of memory optimized SSE (movntq) BitBlt.
note: this compiles but has not been tested. There are almost certainly some bugs.

Could someone write a blank filter for Avisynth 2.5 ?
One that just copies the input to the output.

[sh0dan]

Originally posted by ookzDVD
@Sh0dan,

Your latest Avisynth 2.5 Alpha, build 210103, 2:51PM,
limit the crop for YV12 which should be even number ?

Thank you.

Yes, as it should. In the earlier versions, it corrected the values for you, giving inexact crops. Now you must enter the correct numbers, as you actually should.

[sh0dan]

Originally posted by Richard Berg
I thought we changed that a long time ago? Perhaps the lack of alignment is only affecting YV12?

Alignment is different for YV12, as it is now enforced. The y-plane is garranteed to have at least mod16 width.

@trbarry: I can change the alignement to mod-32 for y-plane, but I would like to have more time to test it properly - there might be some places where frame-alignment is not handled as it should (MPEG2DEC for instance), so it could break some things. My suggestion for now would be:
env->NewVideoFrame(vi,32); //Creates a frame with minimum mod32 y-pitch and mod16 uv-pitch.
env->BitBlt(newframe,oldframe)

And then process the new frame - not the optimal solution, but fairly good.

I'll change the alignment after the first beta.

[Steady]

Here is a blank filter for avisynth 2.5.

[sh0dan]

Stackvertical/horizontal are good for testing bitblit speed.

Edit: Comments on the bitblit replacement.
Seems very nice.

-You shouldn't bail out, if rowsize is not mod 8. You are still able to make rowsize larger, up to pitch. That's what I'm doing in the top of asm_BitBlt. This will help alignment in many cases, since rowsize is quite unlikely to be aligned.

- Very nice inner loop!

- Use "align 16" before often used branch points. I know this routine is mostly memorylimited, but anyway.

[sh0dan]

Cr*p - we still have problems with MakeWritable! The "makewritabe-fix" suggested by Donald, and put in by me affects other parts of the program. :angry:

The bug in temporalsoften was caused by the change in makewritable, so I'll have to test a bit more until beta.

So nothing today - even though the Buc's won ;)

[Guest]

The only thing I recall suggesting was to fix it. :)

Could it also explain the bug with Dup and Cnr2?

[ARDA]

@ Steady

What should we do with both the nothing does filter and the memcopy?
What kind of test would you suggest?
Thanks Arda

[sh0dan]

Originally posted by neuron2
Could it also explain the bug with Dup and Cnr2?

CNR2 is flawed - the change probably only made it more visible. It still changes chroma on a random frame.
The problem in temporalsoften was also a design problem, caused by multiple makewritables calls on the same frame. It shouldn't be so, and it was fixed - so the "makewritable-fix" (wether you want credit or not ;) still remains.

[Guest]

Originally posted by sh0dan
CNR2 is flawed - the change probably only made it more visible. It still changes chroma on a random frame.
The problem in temporalsoften was also a design problem, caused by multiple makewritables calls on the same frame. It shouldn't be so, and it was fixed - so the "makewritable-fix" (wether you want credit or not ;) still remains. I just think we need to take crashes very seriously and get to the bottom of them, especially if the Avisynth core is implicated. I'm not persuaded by your argument about Cnr2 and still think there is a problem in the core. Please see the Dup thread for followup. Thank you.

[Richard Berg]

The problem in temporalsoften was also a design problem, caused by multiple makewritables calls
Calls to MakeWritable when IsWriteable is already true should be a no-op. Given that, I agree with neuron2 that there's still a bug in the core.

I think I will add a null-filter to the core to aid in debugging these things...

[Steady]

Originally posted by ARDA
@ Steady

What should we do with both the nothing does filter and the memcopy?
What kind of test would you suggest?
Thanks Arda
I thought you might put the blank filter in an Avisynth SDK. I find it much easier to start out with something like this rather than a blank project when writing a new filter ;)

As for the memcopy, I was just hoping someone would look over it (as Shodan was kind enough to do). I am testing it now. Preliminary results seem to show it is about 2x as fast. Not that that is a big deal, shaves off about 1/2 ms per frame(500,000 cycles vs 1,300,000 cycles) when it takes roughly 10 ms to decode a huffy source with no processing. Still every little bit helps :)
Originally posted by Sh0dan
-You shouldn't bail out, if rowsize is not mod 8. You are still able to make rowsize larger, up to pitch. That's what I'm doing in the top of asm_BitBlt. This will help alignment in many cases, since rowsize is quite unlikely to be aligned.
Well the unaligned routine isn't really much slower than the aligned routine. (Just a bit of extra overhead maybe 5%). You could even leave out the aligned version if size is an issue. I just figured that blitting full rows is probably true more often than not so why not make it as fast as possible.

[ARDA]

I'm making some tests also just right now , with your new included
BitBlt. Till now I could not detetect any difference.
That's why I'll make longer tests, tyring to arrive to any conclusions.

Thanks Arda

[Richard Berg]

@Steady, sh0dan -

The new BitBlt was causing major corruption for me. (very wacky effects on AviSource'd files; Version() wouldn't even run) I'll see if I can track down the bug.

Also, I changed the if-statement in BitBlt to reflect the fact that the ASM-routine now requires ISSE (not just MMX).

[ARDA]

Same problem here but just when width is mod4 ; mod8 and up works ok.
Maybe this can help to find the bug

Arda

[sh0dan]

Let's save Steadys bitblit for after the beta (Richard - you seem to be working on avisynth.cpp now - could you change it back?)

[sh0dan]

Originally posted by Steady
As for the memcopy, I was just hoping someone would look over it (as Shodan was kind enough to do). I am testing it now. Preliminary results seem to show it is about 2x as fast. Not that that is a big deal, shaves off about 1/2 ms per frame(500,000 cycles vs 1,300,000 cycles) when it takes roughly 10 ms to decode a huffy source with no processing. Still every little bit helps :)

Nice speedup!! What's your test-setup?


I just figured that blitting full rows is probably true more often than not so why not make it as fast as possible.

What do you mean?

Blitting full cachebypassing 8bytes aligned quadwords will be faster than moving individual bytes at the end of each row. The point is that rowsize may very well be non-mod8, but you can in many cases extend rowsize up to the pitch of the frame, thus being able to avoid moving single bytes.

[Richard Berg]

@sh0dan - CVS locks removed

@Steady - I'm not sure row_size<32 means it's not worth it to optimize. I can imagine situations in which you'd want to copy a vertical or "thin" slice of memory (small rows, big height). It'll be slower than horizontal fills no matter what, but could be optimized without too much work if you assume row_size ~= CPU_cache_line and made good use of prefetching.

[Steady]

Originally posted by sh0dan
Let's save Steadys bitblit for after the beta (Richard - you seem to be working on avisynth.cpp now - could you change it back?) Yes, a bug in the unaligned routine. I an testing and tuning the hell out of it now :) I need another day or two. Getting strange results now - sometimes it is over 2x faster, sometimes it is only ~20% faster. I wrote a timing routine and found it is pretty consistant - it is the existing routine that is all over the place. Seems to depend heavily on what kind of source it gets (I am guessing some sources leave a lot in the cache and some don't).
@Steady - I'm not sure row_size<32 means it's not worth it to optimizeThat is just a number I pulled out of my hat. I thought I would look at it again when the routine is final. Still for anything less than a cache line rep movsb is probably not that much slower.
What's your test-setup? I'm glad you asked :) I am using the CPU's TSC (Time Stamp Counter). very handy for timing code.
Here is the current version with test routines but I am working on it right now so it will change in a couple of hours.

[sh0dan]

The very different results are to be expected - some blits will be from recently used frames/planes and with 64+256kb data cache on Athlon, it will be able to hold the entire frame in cache in many cases. That way it only has to write to memory.

This is also why we should have in mind that it would be better to return the _source_ frame to filters, when a copy has been made. That way they might be able to read the entire frame from cache.

[Boulder]

Originally posted by trbarry
My DctFilter does not have AvisynthPluginInit2. SansGrip has made an improved version somewhere that also supports YUY2 however it requires VS7 to build, which I don't have.


Tom, have you updated the filter? I think that SansGrip only ported it to AVS2.0x. As this is one that I currently use in every MPEG-1 encode I do, I'd really like to be able to use it with the latest AVS2.5 version as well:)

Thanks in advance!

[Steady]

Originally posted by sh0dan
The very different results are to be expected - some blits will be from recently used frames/planes and with 64+256kb data cache on Athlon, it will be able to hold the entire frame in cache in many cases. That way it only has to write to memory.

This is also why we should have in mind that it would be better to return the _source_ frame to filters, when a copy has been made. That way they might be able to read the entire frame from cache. A good idea. I noticed the newest P4's have a 512KB L2 cache. That is just about the size of a 720x480 YV12 frame.

[trbarry]

"Tom, have you updated the filter?" (DctFilter)

Boulder -

Sorry, I haven't done anything on that one yet. I blotted my own source with Sansgrip's before realizing it won't compile on VS6. It wouldn't be too hard to fix if one doesn't magically appear from somewhere. ;)

I don't want to lose his YUY2 support but I don't want to upgrade to VS7 yet either. ($$$) So I'm procrastinating for the moment.

- Tom

[Steady]

Just missed the beta deadline - arg. Here is the final optimized BitBlt, with (ugly) testing routines. Typical speed increase is about 40% on my system but it varies wildly depending on the source. One note: it makes a significant difference (~20%) which order you blit the planes for YV12, best seems to be V,U, then Y.

If an optimized memcpy would be useful I could write that also.

Now that 2.5 beta is out, what about planar formats other than YV12?
Like YUV4:4:4 (YUV4? YUV24?). When the emphasis is on quality rather than speed it would be nice to have full resolution on all planes (particularly before resizing). An option for RGB planar would be nice also. What do you think?

[Richard Berg]

It's something to consider, for sure. Also, as more people get SSE2-enabled CPUs, we might want to look at 16-bit-per-channel formats...

Soon as sh0dan tidies up the CVS we can go nuts experimenting with this stuff in a separate branch.

[sh0dan]

Yes - I'll move things around a bit (get 2.0 out in a new branch, moving 2.5 to MAIN).

My own inital though on a 4:4:4 was a 15 bit per component high quality mode (with an unused "sign" bit). That would give the best possibilities for SSE optimizations, ans still retain superior quality. There is no official 16 bit 4:4:4 mode, so we might as well create out own.

[Richard Berg]

Do you think it should be YUV or RGB? There are a lot of good reasons to keep it YUV, but the one thing that keeps bringing me back to RGB is the support for alpha channel. As long as we're making up our own format, how does YUVA sound?

BTW, are we talking planar or packed?

[Steady]

How hard would it be to add a 'generic' non-standard format? (no fourcc code). Just specify CUST (custom) or something as the 4cc. Then you (the plugin writer) would choose packed, planar, or interleaved; How many colors (ie 3 for RGB,YUV; 4 for RGBA etc.); how many bits/pixel for each color. This would allow all sorts of things, like a Ycc format other than YUV (UV was choosen more for easy computation than accuracy), greyscale video, and who knows what else.

Interleaved is something Avery Lee once suggested; in between packed and planar. Instead of a Y plane, U plane, V plane, you would have a row of Y and a row of U and a row of V. Or for YV12 a row of Y and a row of packed UV. This would make processing easier for certain kinds of routines.

[sh0dan]

Definately YUV. Alpha can be implemented the same way as RGB.

However! I'm not sure that a in-picture alpha is necessarily a good thing. Implementation and maintenance-wise it would be much better if alpha are used from luma from another image.
Making filters as layer take the chroma from another image as alpha is a much easier and IMO just as good solution. That would also make YV12 alpha blending possible.
RGB32 alpha is at best unsafe - many filters trash it when they process the image.

[scmccarthy]

@Richard@Steady&sh0dan

As long as we're making up our own format, how does YUVA sound? This may not be quite true, depending on what you mean. In my investigations of color space, I found reference to 4:2:2:4, where the last 4 represents an alpha channel. It is not a fourcc code, but it is a format. It is a 4, because it is always as large as the Y samples regardless of how many chroma samples there are (ie 4:1:1:4, 4:2:0:4, 4:4:4:4). I envision the alpha channel for YUV as a separate plane for both planar and interleaved versions of YUV. The only way this solves anything for you is if you investigate exactly how the 4:2:2:4 format is implemented elsewhere.

And as long as we are talking about this now, I want to reiterate my desire to see avisynth support the NY12 fourcc code. In the future, avisynth will probably expand its support of Direct Show, which might cause problems as Microsoft is making noises threatening to drop support for YV12 in favor of NV12. Did you notice? On the Video Rendering with 8-Bit YUV Formats page: It is expected to be an intermediate-term requirement for DirectX VA accelerators supporting 4:2:0 video. The same statement is made regarding YUY2.It is expected to be an intermediate-term requirement for DirectX VA accelerators supporting 4:2:2 video. Obviously we already support the second one. Microsoft likes NV12 because both planes have the same pitch. It has a Y plane and a plane of interleaved uv samples. It would be very easy to convert between the two except, I need a way to put the NV12 code in the header. Actually, all you'ld need implemented is the following code:vi.pixel_type = VideoInfo::CS_NV12;
GetPitch(PLANAR_UV) // returns the same as GetPitch(PLANAR_Y)
GetHeight(PLANAR_UV); //returns the same as GetHeight(PLANAR_U) Only the first one is needed really. Just give me the NV12 code in the header.

Maybe it doesn't matter if the fourcc codes are not used with Direct Show anyway.

Here's some links that refer to 4:4:4:4 YCbCr with an alpha channel:
Quicktime for Linux (http://heroinewarrior.com/quicktime.php3)
LMA - Linus Media Arts (http://www.lmahd.com/SDIO.html)
I guess mainly it is standard for professionals, not for consumer products. Still, it would be nice to have some form of YCC alpha channel support internally. From there anyone can write a plugin that implements a specific format.

Stephen

[Bidoche]

Damn, I knew it !!!
(that I should have made a YV12VideoFrame subclass of Planar and not assumed Planar = YV12)
:p

[hakko504]

Originally posted by Bidoche
Damn, I knew it !!!
(that I should have made a YV12VideoFrame subclass of Planar and not assumed Planar = YV12)
:p Well there's a lot of time to change that before 3.0 hits the market :D

[sh0dan]

I don't think MS is going to drop YV12 anytime soon. It's widely used, almost as much as YUYV (YUY2).
Anyway I cannot see any significant gains in using NV12 internally - adding it as an output option should still be possible, but I see no need for filters to support it - it's clumsy, and only usable when U and V are interdependant. Even then it's just as easy processing YV12.

[scmccarthy]

I fail to see a difference between an output plugin and an internal filter. All I am asking for is a new pixel type for the video info:vi.pixel_type = VideoInfo::CS_NV12; with a matching fourcc type in the header.

Attached is a plugin that won't compile yet, but I hope can be added as an internal filter for avisynth.

and I agree that this filters main usefulness would be to add it at the bottom of a script for codecs that can read NY12. I think Microsoft likes all frames to have the same pitch. Perhaps it saves memory that way.

Stephen

[sh0dan]

Guess it could be added - however I fail to see the purpose - do you have conversion routines to/from all the currently supported colorspaces?

[scmccarthy]

@sh0dan

The above attachment is a conversion routine from YV12 to NV12. I did it to demonstrate what is needed to allow conversion routines to work in NV12 space. Attached is the converse conversion routine from NV12 to YV12.

Altogether, this is a proposal to add three things to the avisynth header:

1) CS_NV12, of course.
2) PLANARUV, which returns a plane that is the same width as the Y plane, but half its height.
3) I created IsNV12() in the source of the attachment below. This would also go in avisynth.h however.

The big problem with NV12 is what it should return for interleaved. It has a plane of interleaved chroma samples. In all other ways it is the same as YV12. The MSDN YUV site does explain both color spaces adequately. Again, the advantage is supposed to be that having all planes with the same pitch and width allows the data to be stored in one big rectangle. (I hope that makes sense to you, you'd see what I am talking about if you look at the pictures on the MSDN site.)

My interest in this is being curious if there are or soon will be applications that can read NV12 directly and if this would allow those applications to work that way. For instance, if Microsoft is so gung-ho on this color space, does that mean that it already works with graphedit or WMP? It would be easier to implement this to find out than try to look for the answer.

Honestly, I am not sure what DirectX VA accelerators are, except it is part of DirectShow and definitely part of DirectShow for Windows XP service pack 1. Well, and that VA must stand for video accelerator. Most importantly to me, if we throw it out there, it will probably be useful sometime in the future and someone might use it in a way we cannot anticipate. My best guess is it will work with graphedit.

Stephen

[sh0dan]

To be frank, I think you're better off testing it yourself - do you have the software to build AviSynth? Not to be arrogant, but there are still some issues we need to resolve that to me seems more important.

When I implement it, it'll mean that we'll have to support it, ie. adapting the internals for it every time there is a change. It also means "one more potential error", which will only bring confusion, if it is added as a hack.

Do you have any concrete docs on why it should be good - what software and hardware is supporting it?

[scmccarthy]

This is just a proposal. Bioche already mentioned that AviSynth assumes that PLANAR and YV12 as equivalent, as though there are no other planar color spaces worth supporting. I don't know what they mean by it, but Microsoft's statement: intermediate-term requirement for DirectX VA sounds ominous.

So it is good to consider right now that NV12 might be needed in the future.

For now I'm concentrating on how to write a good plugin, rather than building Avisynth. But everything I write could be useful as an internal plugin, so I've thought of it.

I'm not as anxious for this as it seems. My thinking is if Microsoft thinks NV12 is better than YV12 for some reason then we should support it.

Stephen

[Bidoche]

I guess maybe we may want to add NV12 support as import and export, but as an internal colorspace to work with... I dunno

[scmccarthy]

@bioche

I honestly don't understand the difference. Unless you mean you do not want to require every filter to handle it. That I whole heartedly agree with. The only support I offer for using it is the vague theory that some applications *might* support it. Plus Microsoft's approval of it, which may mean nothing. Nothing, that is, of practical importance to avisynth.

My thought is that if setting pixel_type to CS_NV12 causes avisynth to output the appropriate fourcc code in the header now, we might be prepared in the future if NY12 becomes a more important colorspace.

Meanwhile, the only sure method for finding out if applications can use it is to try it. It is not that important to me, but all I am asking for is the minimum that would allow the two filters I already wrote to compile. I wrote them mainly to figure out what that minimum is. They are not software so much as a umambiguous proposal.

I suppose that if I don't research it to the point that I find at least one application that can really use it, there is not much point in it for now.

Stephen

[sh0dan]

AviSynth 2.5 does NOT assume YV12 == planar. Everything has been designed so that other planar formats can be accepted without any problems.
YUV 4:4:4 could in principle be added easily but since there is little use for it, and it would require rewrites of about 25% of the filters it isn't. Adding other kinds of planar formats (with is just as easy) would be just as easy - only problem is that not all filters know they're capable of processing not only YV12, but all planar images.


Adding a 16 bit YUV is another matter though, but still doable within the current design.

But NV12 isn't planar - it's a strange planar/interleaved hybrid, hopefully doomed as a strange idea MS got and nobody ever implemented. ;)
Adding support for NV12 will probably only create a mess.

[Bidoche]

@sh0dan

I was the one assuming that planar == YV12 (in my 3.0 framework)
but that's not really a problem, just some subclass renaming.

@scmccarthy

I could probably add NV12 support in 3.0 since VideoFrame is polymorphic it won't mess the rest, but for 2.5 it's out of question.
It's no time to try structural changes in 2.5 when everything is not even ok and we are planning a bigger jump anyway

And my nick is Bidoche with a d.
I don't understand how all of you manage to miswrite it..

[Guest]

@Bidoche

Originally posted by Bidoche
And my nick is Bidoche with a d.
I don't understand how all of you manage to miswrite it.. It's intentional; you're French. ;)

Seriously though, as English speakers our brains latch onto the "Bi" prefix and that round part of the "d" and subconsciously we perceive it as "Bio". Careless Yanks, I know. :)

[trbarry]

Assuming this is still the update thread, see

www.trbarry.com/DctFilter.zip

Avisynth 2.5b, pluginit2, YV12, and SansGrip's YUY2 support.

- Tom

[scmccarthy]

Everything has been designed so that other planar formats can be accepted without any problems. Part of why I bring it up is to make sure avisynth IS being designed so that any color format can be added later, as things change.@sh0dan That's right, I was just repeating what biDoche said. (Neuron2 was almost freakishly right, very perceptive.)hopefully doomed as a strange idea MS got and nobody ever implemented. Although NV12 interests me, I see your point. Unless someone can demonstrate that people are implementing it, there's no point in implementing ourselves.I could probably add NV12 support in 3.0 since VideoFrame is polymorphic it won't mess the rest, but for 2.5 it's out of question. Well, in a way I am pushing it just to get it on the table. Due to Microsoft's backing, I am guessing that all sorts of video companies have started support for NV12, card makers like NVidia perhaps, and it's definitely part of DirectShow now. So in a couple of years, it might be an important standard, or not.

Stephen

[trbarry]

A format like that was a seductive idea and I even thought I had invented it once. ;)

An early (unreleased) version of my CheckeredInterlace filter used something like that. But as I got more used to YV12 it became obvious that in YV12 I could often call the same code for both the U and V planes and sometimes even for the Y plane. So YV12 programming is really easier than NV12 as far as I'm concerned. I'd just let codecs handle it.

- Tom

[scmccarthy]

@tom

I don't want to belabor the point, but I think the reason Microsoft likes it is because all planes have the same pitch and rowsize. Maybe that lets you stack them on top of one another and processes them both in the same loop? Whatever advantages other formats have, as you learned, it is *often not* worthwhile to change the format in a filter just to make processing easier. (Did I say never?) We can't appreciate how much easier NV12 is until we live with it for a while. It just always seems easier at first to work in more familiar color spaces. But it is a moot point unless it becomes more widely supported anyway. I am very happy with sh0dan's sense of priorities.

Stephen

[Guest]

The fact that the UV planes in YV12 are smaller than the Y plane makes low-level optimization of Decomb very difficult and I still don't know what I'm going to do about it. I can't just do the planes totally separately. There is a common combing map that must be an OR of all the planes. I just mention this as a concrete instance of Stephen's point.

[issa]

I am now trying avisynth 2.5 beta with mpeg2dec3 v1.0.0.
I found out that SeparateFields().Weave() will not product
right interlace result. Is there a problem in Weave()?

*edit*
I fixed the problem with adding AssumeBFF() before Weave().
However, TMPEG said the clip is TFF, is there a problem with
field detect in mpeg2dec3 or avusynth ?

[Guest]

Originally posted by issa
I am now trying avisynth 2.5 beta with mpeg2dec3 v1.0.0.
I found out that SeparateFields().Weave() will not product
interlace result. Is there a problem in Weave()? There certainly seems to be something strange because the following scripts give output clips with different heights by a factor of 2:

AssumeFieldBased() // produces double height clip!
SeparateFields()
Weave()

...versus:

AssumeFrameBased()
SeparateFields()
Weave()

[sh0dan]

Originally posted by Steady
Just missed the beta deadline - arg. Here is the final optimized BitBlt, with (ugly) testing routines.

I still get crashes in the unaligned loop on complex scripts.

Point of crash:

memoptU_prewrite8loop: //write out odd QW's so 64bit write is cache line aligned
cmp ecx,eax //start of cache line ?
jz memoptU_pre8done //if not, write single QW
-> movq mm7,[esi+ecx]

Script:

stackvertical(last,last)
stackhorizontal(last,last)
reduceby2()
stackvertical(last,last)
stackhorizontal(last,last)
reduceby2()
flipvertical()
fliphorizontal()
swapuv()
reduceby2()

I don't think all (or any) the filters are necessary. It crashes right before output, so it's probably because the output isn't very well aligned.

The size of the video at the crash is:
rowsize: 180
dst_pitch is 180, src_pitch is 184
height: 144

[Steady]

I am sorry I missed this till sh0dan PM'd me. It turns out that it is crashing because with YV12 on the U and V planes the pitch was not mod8 (width 184, UV width 92 gave a pitch of 92).

I had made the assumption that the pitch was ALWAYS QW aligned (modulo 8). Evidently that is not true for YV12. I can make it check the alignment for every row, but this will slow it down a little bit. I guess my question is; Is the pitch allowed to be not mod8 for YV12 or is this a bug?

[Richard Berg]

Yes, pitch is allowed to be non-mod-8. There was a big discussion awhile ago where we decided to allow unaligned sizes up to the minimum required by the format (mod 2 in general, mod 4 when interlaced).

Nothing says we have to give unaligned sizes preferred treatment, though -- if it'll increase speed for "normal" frame sizes, I wouldn't feel bad about doing a single test at the beginning and letting it revert to the C code for non-QW-aligned sizes, so long as we add a FAQ entry or similar as documentation.

[trbarry]

Yes, pitch is allowed to be non-mod-8. There was a big discussion awhile ago where we decided to allow unaligned sizes up to the minimum required by the format (mod 2 in general, mod 4 when interlaced).

I though it was agreed size could vary non-8 but pitch would be 8 even in chroma. (so total pitch at least 16)

Not sure, but I think some of my filters rely on that too.

- Tom

[scmccarthy]

@Richard

You are confusing pitch with height and width. As tom points out, the decision was to let the Y plane pitch be mod16, making the U and V planes mod8.

Interlaced versus frame-based only affects the modulus base 2 for the height.

Stephen

[sh0dan]

(Copy/Paste from my PM)

Pitch is only guarranteed to be aligned for filters! When bitblitting from AviSource for instance pitch can only be mod4. That's why there is an AlignPlanar class, that always gets applied efter AviSource, DirectShowSource and some conversions, that realigns to a mod 8 pitch, if it is not so already.

Output (as the case here) also requires a bitblit to a mod4 pitch - that's AVI specs.


So - you filter writers can still safely assume pitch = mod8, luma pitch = mod 16!

[Steady]

The fix turned out much simpler than I thought. Shouldn't slow it down significantly. I should have thought of it before.

[Richard Berg]

You're right, I read his post incorrectly. Don't listen to me ;)