AviSynth 2.5 updates

[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