AvsPmod (Windows_x86) mod

[gispos]

Originally Posted by real.finder

hi gispos
since I cant live without AvsPmod, is it possible to make it work in linux? https://forum.doom9.org/showthread.p...80#post1932680

Sorry, sorry no.
I don't have Linux, I'm no longer the youngest and don't feel like doing Linux.

[gispos]

Third thread test version.
Changed some things, unfortunately I didn't write anything down this time, so without change.log

mediafire
x64 https://www.mediafire.com/file/98wkb...%2529.zip/file
x32 https://www.mediafire.com/file/ldaaw...%2529.zip/file

sendspace
x64 https://www.sendspace.com/file/vncsut
x32 https://www.sendspace.com/file/duudy3

@real.finder
Did AvsPmod work before the avxsynth change? Is the filename still 'libavxsynth.so'

[real.finder]

Originally Posted by gispos

@real.finder
Did AvsPmod work before the avxsynth change? Is the filename still 'libavxsynth.so'

don't know, I rarely use Linux (and I do it in virtualbox)

the file now is libavisynth.so

[l00t]

I would like to note a bug:

Latest beta simply freezes and quits upon opening avs frameserver (even with a single line of Version() ) when only SSE4.2 is present as highest instruction set (i7-980). It works fine on CPUs with AVX and AVX2 (i7-3960X & Xeon Gold 6152)... probably this has something to do with threading.

Latest stable works fine, however, the app releases the avisynth.dll dramatically slowly (approx half min) on the SSE4.2 system...

(AVS+ 3.7.0 was used)

[gispos]

I do not like such messages.

Originally Posted by l00t

I would like to note a bug:

Latest beta simply freezes and quits upon opening avs frameserver (even with a single line of Version() ) when only SSE4.2 is present as highest instruction set (i7-980). It works fine on CPUs with AVX and AVX2 (i7-3960X & Xeon Gold 6152)... probably this has something to do with threading.

Routines that are not thread save and are taken over by AVX for other CPUs are likely to be executed on the threads.
If so, I can't do anything about that.

What happens if you turn off the threads when loading the clip and turn them on again later?

Originally Posted by l00t

Latest stable works fine, however, the app releases the avisynth.dll dramatically slowly (approx half min) on the SSE4.2 system...

(AVS+ 3.7.0 was used)

If AvsPmod has problems with freeing up the memory, there is apparently a problem with the interaction of your system and avisynth.
AvsPmod does almost nothing and passes it on to avisynth.
avs_release_video_frame, avs_release_clip, avs_delete_script_environment

Have you ever tried an Avisynth version for Windows XP?
Maybe Ferenc or FranceBB also reads here and can write something about it?

I can't think of anything better, you can download AvsPThump here.
It also uses Avisynth in separate threads.
Create a few bookmarks in AvsPmod (at least 50), save the bookmarks in the script and save the script.
Then open this script with AvsPThumb, the thumbnails should be created in a few seconds. If not, or a crash follows ... you are unlucky

[gispos]

Originally Posted by l00t

Well, in principle the first frame should do it, as in most cases it will be the same over the entire footage.



colormatrix should be conserved (all filters should respect it and changes should be followed) and different clips could only be merged if the matrices are matched/converted previously... otherwise you can end up with funny results...

PS: VSEditor is handling this in a quite correct way, so it's not impossible...

I'm not thrilled with this feature After a few tests I turned it off.

Too many filters do not pass the frame properties and the result is not satisfactory.
First Rec601, I activate a filter and the color changes because there are no more properties.
It's a back and forth that is just annoying.
Then I would rather read the matrix myself (propShow) and adjust the display accordingly if necessary.

This is not worth the effort for me at the moment (menu adjustments, extra variables, Rec must be displayed, menu status must change, etc.)

[FranceBB]

Originally Posted by gispos

Have you ever tried an Avisynth version for Windows XP?
Maybe Ferenc or FranceBB also reads here and can write something about it?

I just tried version 2.6.6.8.3b on Windows XP x86 which supports SSE4.2 only and I don't see any problems: https://i.imgur.com/tUejsKW.png

I also tried the new x86 build on Win10 with an AVX2 capable CPU and I didn't have any problems. As to the WinXP build per se, the difference between that one and the Win7 and up one I think is essentially the /Zc:threadSafeInit which I don't think it's gonna help in this case, but it might be worth trying, although I'm pretty sure his problem is related to something else...

EDIT: Actually the x64 version on Win10 with Avisynth x64 crashes...

[l00t]

Originally Posted by FranceBB

I just tried version 2.6.6.8.3b on Windows XP x86 which supports SSE4.2 only and I don't see any problems: https://i.imgur.com/tUejsKW.png

I also tried the new x86 build on Win10 with an AVX2 capable CPU and I didn't have any problems. As to the WinXP build per se, the difference between that one and the Win7 and up one I think is essentially the /Zc:threadSafeInit which I don't think it's gonna help in this case, but it might be worth trying, although I'm pretty sure his problem is related to something else...

EDIT: Actually the x64 version on Win10 with Avisynth x64 crashes...

Oh yes, I forgot to mention that I use W10 20H2 x64 with x64 AVS+ on all of my machines...

Regarding the colormatrix: Since some filters erase properties (as they are not 100% conform with 3.7.0 standards, yet) I would suggest to display according to the colormatrix if the property exists, otherwise fall-back to resolution based.

[gispos]

Originally Posted by FranceBB

EDIT: Actually the x64 version on Win10 with Avisynth x64 crashes...

With threads? and without threads?
I'm slowly losing interest, it's just annoying and is not worth all the effort. I do not know if I will continue.

Try this version
x64 https://www.sendspace.com/file/33l7sl

Wasn't actually meant to be published yet. Whatever, description will come later.
Display YUV -> RGB conversion (Resolution-based, BT.709, BT.601) now script related
There are a few new entries in the menu Display > YUV -> RGB

[gispos]

But it also sucks, for 2 weeks I've been working on this stuff and putting test versions in here ... for what? there is no response after all.
I still don't know if any test version worked and only now has an error occurred. That's puke my dear users.

One had reported problems (after almost 2 weeks), so I do not assume that it does not work.
I can save the whole thing here and just put a version on github every now and then.

[FranceBB]

Originally Posted by gispos

But it also sucks, for 2 weeks I've been working on this stuff and putting test versions in here ... for what? there is no response after all.
I still don't know if any test version worked and only now has an error occurred. That's puke my dear users.

The thing is that I don't really use Avisynth x64 except on my work servers in which I clearly don't have AVSPmod as they're... well... servers.
I do have it on my computers and I use it on a daily basis, however I use the x86 version 99.9% of the time as I have all the plugins I collected over the years as x86 and only a very few of them as x64, so... I didn't notice. But for me, everything was fine on x86. It has been working just fine on Win10, while on XP the new "waiting for Avisynth" message is slightly truncated at the very bottom in the UI, but it doesn't really matter as it's just a waiting message.

Here: https://i.imgur.com/i1835qD.png

Originally Posted by gispos

Try this version
x64 https://www.sendspace.com/file/33l7sl

Works just fine on my end!
Let's wait for the other guy...

Originally Posted by gispos

One had reported problems (after almost 2 weeks), so I do not assume that it does not work.
I can save the whole thing here and just put a version on github every now and then.

I mean... I do test and for me x86 works just fine.
Every time you release a new beta, I download it and put it on my Win10 and XP, but both are using the x86 version which doesn't have any issues and works great, both with SSE4.2 and AVX2, so nothing to report on my end.
Since the other user reported something, I decided to try to reproduce his issue, that's all.
Don't be upset Gispos, you're doing a great work.

[l00t]

Thank you for your efforts. I have tested the new version on my SSE4.2-only system (everything is x64). The outcome:

With threads enabled (Access AviSynth in threads): Version() and ColorBars() are working fine, however, program still crashes with DGSource.
With threads disabled: Everything is fine

Regarding the colormatrix, please give me more time to test

If I notice any more strange behavior, I'll let you know for sure.

And I also would like to make an excuse, like FranceBB. I use various environments for encoding videos, and on high-core systems (used in 70% of my time) VapourSynth performs superior, compared to AVS+, so from there I can only report bugs present in VS and VSEdit...

Originally Posted by gispos

With threads? and without threads?
I'm slowly losing interest, it's just annoying and is not worth all the effort. I do not know if I will continue.

Try this version
x64 https://www.sendspace.com/file/33l7sl

Wasn't actually meant to be published yet. Whatever, description will come later.
Display YUV -> RGB conversion (Resolution-based, BT.709, BT.601) now script related
There are a few new entries in the menu Display > YUV -> RGB

[gispos]

Originally Posted by l00t

With threads enabled (Access AviSynth in threads): Version() and ColorBars() are working fine, however, program still crashes with DGSource.
With threads disabled: Everything is fine

Is the SourceFilter then DGDecodeNV.dll with Cuda?

Is the CPU or the SourceFilter the problem, so:
What happens with other SourceFilters? AviSource, Directshow, ffmpeg, LWLibavVideoSource
That is the question that interests me most.

Originally Posted by l00t

Regarding the colormatrix, please give me more time to test

Is not completely finished yet. With Matrix 1 Rec601 is set with everything else Rec709.
I don't know yet what other values there are, maybe someone can tell me.

To display the conversion used, there is the value %DYR under the settings of the statusbar.
If no matrix is found in the properties, the matrix that was written in the script is used.

@FranceBB crashes AvsPmod x64 when you use DGSource?

[videoh]

Originally Posted by l00t

With threads enabled (Access AviSynth in threads): Version() and ColorBars() are working fine, however, program still crashes with DGSource.
With threads disabled: Everything is fine

Can you post your script using DGSource please? DGSource should be MT_SERIALIZED. It is by default and you should not override that.

[JKyle]

Originally Posted by videoh

DGSource should be MT_SERIALIZED. It is by default and you should not override that.

That's a very informative tip.

BTW, how about DGHDRtoSDR and DGTonemap?

(Sorry about the digression. )

[StainlessS]

I thought ALL(or Nearly all) source filters need to be MT_SERIALIZED.
Anybody, is this correct ?, if nearly all, what are exceptions.

EDIT: From SetMTMode.avsi

#    5. Starting from AviSynth+ r2069, AviSynth+ will now automatically recognize source filters.
#       If it sees a source filter which has no MT-mode specified at all, it will automatically use mode 3 instead of the default MT mode.
#       This is great  for source filters as in their case it rarely hurts performance and they often need mode 3 anyway, and it will help yet
#       unclassified source filters perform correctly without any user action. One step closer to  the "it just works" target.

# ...

# Source plugins
SetFilterMTMode("DGSourceIM",          MT_SERIALIZED)     #DGDecIM        beta 50   2015/10/10
SetFilterMTMode("DGSource",            MT_SERIALIZED)     #DGDecNV           2046    2014/01/01 - GPU decoding
SetFilterMTMode("DSS2",                MT_SERIALIZED)     #DSS2          2.0.0.13   2014/11/10
SetFilterMTMode("FFAudioSource",       MT_SERIALIZED)     #FFMS2            V2.22   2015/10/12
SetFilterMTMode("FFImageSource",       MT_SERIALIZED)     #FFMS2            V2.22   2015/10/12
SetFilterMTMode("FFFFmpegSource2",     MT_SERIALIZED)     #FFMS2            V2.22   2015/10/12
SetFilterMTMode("FFMS2",               MT_SERIALIZED)     #FFMS2            V2.22   2015/10/12
SetFilterMTMode("FFVideoSource",       MT_SERIALIZED)     #FFMS2            V2.22   2015/10/12
SetFilterMTMode("FRIMSource",          MT_SERIALIZED)     #FRIMSource       V1.26   2016/01/16
SetFilterMTMode("JpegSource",          MT_SERIALIZED)     #JpegSource       --->    2014/04/19
SetFilterMTMode("LSMASHAudioSource",   MT_SERIALIZED)     #LSMASHSource     r877    2016/03/09
SetFilterMTMode("LSMASHVideoSource",   MT_SERIALIZED)     #LSMASHSource     r877    2016/03/09
SetFilterMTMode("LWLibavAudioSource",  MT_SERIALIZED)     #LSMASHSource     r877    2016/03/09
SetFilterMTMode("LWLibavVideoSource",  MT_SERIALIZED)     #LSMASHSource     r877    2016/03/09
#SetFilterMTMode("RawSource",          MT_SERIALIZED)     #RawSource26      20160528    2016/05/28

[real.finder]

Originally Posted by gispos

x64 https://www.sendspace.com/file/33l7sl

I did try it and seems work fine, thanks

I like how avspmod not crash if there are some problem in the script

[videoh]

Originally Posted by JKyle

BTW, how about DGHDRtoSDR and DGTonemap?

Gotta check what I did. Will report back. I think they can be NICE as they don't use the (single) video engine.

[gispos]

Originally Posted by real.finder

I did try it and seems work fine, thanks

I like how avspmod not crash if there are some problem in the script

Thanks for the feedback.
I couldn't really test it yet, in the past avisynth almost always got stuck when I used QTGMC and MCTD together,
at the moment avisynth just doesn't want to crash anymore, what a bummer.

[gispos]

AvsPmod 2.6.6.9

** The syntax for the preview filter end has changed. The Preview Filter Area must now be completed with **/
-   /**avsp_filter
-   sharpen(0.4)
-   **/
* First public release with thread access to avisynth on create/release clip and get frame
- on/off options menu 'Access Avisnth in threads'
- default turned off, but I recommend turning on the threads and only to deactivate if there are problems.
- for more info please reade the readme_threads.txt
* Display YUV -> RGB conversion (Resolution-based, BT,709, BT.601) now script related.
- conversion coefficient can be read from the source (frame properties). Or from the script when it was previously manually stored in the script. 
- an asterisk * is preceded when the matrix has not read from the source ( *Rec601 ) 
- under Program Options > Configure Statusbar, there is a new value %DYR to display the used matrix in the status bar.
* Preview filter handling with the sliders revised. Should everything run a little better. ;)
* Still some changes

Crap: I turned on the threads as default. So test it yourself.