Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 22nd May 2020, 18:33   #181  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,544
The others may conflict with vapoursynth definitions?
pinterf is offline   Reply With Quote
Old 22nd May 2020, 18:34   #182  |  Link
stax76
Registered User
 
Join Date: Jun 2002
Posts: 6,291
Thank you, unfortunately Error C2365 remains.
stax76 is online now   Reply With Quote
Old 22nd May 2020, 18:38   #183  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 1,423
Quote:
Originally Posted by pinterf View Post
Have you tried the binaries in my previous post?
Nope, I am using the v8 interface wrapper.
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 22nd May 2020, 18:44   #184  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,544
Quote:
Originally Posted by tormento View Post
Nope, I am using the v8 interface wrapper.
This latter is good for both v6 and v8, I hope.
pinterf is offline   Reply With Quote
Old 22nd May 2020, 18:46   #185  |  Link
stax76
Registered User
 
Join Date: Jun 2002
Posts: 6,291
Quote:
Originally Posted by pinterf View Post
The others may conflict with vapoursynth definitions?
I think so, will try to workaround it tomorrow.
stax76 is online now   Reply With Quote
Old 22nd May 2020, 18:49   #186  |  Link
Morku
Registered User
 
Join Date: Jul 2012
Posts: 169
Quote:
Originally Posted by Zathor View Post
Btw. the wrapper is only used for some internal functions (preview, deint check, audio encoding) but not when encoding the video.
Uh, this must be the reason, why the AVS Script Creator window turns black now.

https://i.imgur.com/E14i11E.gif

I have updated to AviSynth 3.6 and replaced the Wrapper from pinterf.
When I load a avs in the AVS Script Creator (I have tried ffmpegsource and dgsource, so it is unrelated) the preview turns black after 1 second. Also the Input DAR changes? You see in gif.

But when I load in Input and click Reopen Video Preview, the preview stays open fine.
No errors in the log when I reproduce the issue.

And thank you for all the time and support of MeGUI
Morku is offline   Reply With Quote
Old 22nd May 2020, 18:54   #187  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 1,423
Quote:
Originally Posted by pinterf View Post
This latter is good for both v6 and v8, I hope.
It works both enabling and disablint "Always use the included AviSynth", however I always get the following log:
Code:
--[Information] [22/05/2020 19:50:31] No package requires an update
-[Information] AviSynth Wrapper
-[Information] File Version: 3.5
-[Information] File Date: 02-04-2020
-[Information] File Name: AviSynth+ 3.5 (r3106, 3.5, x86_64)
-[Information] File Path: d:\eseguibili\media\megui\avisynth.dll
-[Information] AviSynth Version: AviSynth+ 3.5 (r3106, 3.5, x86_64)
It seems like MeGUI is ignoring that setting or there is something wrong in the logging.
__________________
@turment on Telegram

Last edited by tormento; 22nd May 2020 at 18:57.
tormento is offline   Reply With Quote
Old 22nd May 2020, 20:27   #188  |  Link
stax76
Registered User
 
Join Date: Jun 2002
Posts: 6,291
I'm not using these enums so just out comment them.

Maybe there is still time to rename these things?
stax76 is online now   Reply With Quote
Old 22nd May 2020, 21:28   #189  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,544
Yep or I'll define them as class enums. I do not think that many of you around the world is using them presently
pinterf is offline   Reply With Quote
Old 23rd May 2020, 01:13   #190  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 859
Quote:
Originally Posted by qyot27 View Post
I don't know. My experience using a debugger is restricted to gdb, which won't work with the MSVC builds.
I see...

Quote:
Originally Posted by pinterf View Post
Have you tried both the xp installer and the fileonly versions (just to exclude a wrongly packaged dll version)?
I installed the vcredist one and it didn't work on XP, so then I installed the xp installer (without vcredist) and I still got an access violation.

I even tried with

Code:
SetMaxCPU("none")
ColorBars(848, 480)
Still access violation everywhere (AVSPmod, AVSMeter, VirtualDub, avs4x264mod, avs2yuv, empty file in ffmpeg - although it recognizes the A/V stream) but on MPC-BE.
On MPC-BE it works with its internal functions and ffms2 but as soon as I try to use some filters it doesn't...

I then installed the normal non-xp version and I've still got the same ACCESS VIOLATION error.
I re-installed again the XP version, I uninstalled 0patch (it provides security patches past Microsoft EoS in July 2019) and I also uninstalled the Antivirus (Avast Premier) and ran it again: same ACCESS VIOLATION.

I then downloaded the files only version, I manually substituted Avisynth.dll and DevIL.dll in Windows\System32 from the x86-xp folder, I tried to run AVS and I've got an ACCESS VIOLATION.

Then I finally tried the x86 non XP one files only version and I manually substituted Avisynth.dll and DevIL.dll in Windows\System32 once again.
Guess what? ACCESS VIOLATION.

On Windows 10 the normal installer x86 works like a charm on the same computer with the very same hardware.

At this point I said: "It must be something forked from Avisynth Neo!"
so I installed Avisynth Neo x86 r2827 and it gave me ACCESS VIOLATION. The very same behavior of Avisynth 3.6.0!
"Aha!"
It seems that they share the same behavior...

Of course, reverting to Avisynth+ 3.5.1 works and everything works again.
As I said, I have no idea about how to debug it other than saying that it doesn't have any missing dependencies when
I look at it with Dependency Walker and it's supposed to work fine, but it doesn't. I generally rely on AVSMeter but it just shows ACCESS VIOLATION just like any other program this time, so I don't know.
Any idea?
I don't know if you have an XP VM to test, but if you want something to test, I would happily let you login in mine via Anydesk or Team Viewer or RDP or whatever you want if you wanna take a look at how it behaves on XP.
FranceBB is offline   Reply With Quote
Old 23rd May 2020, 01:59   #191  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,169
Test this one (32-bit only):
http://www.mediafire.com/file/we5m23...nosimd.7z/file
qyot27 is offline   Reply With Quote
Old 23rd May 2020, 05:21   #192  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,544
This is weird, - I'm using cmakegui, checked the XP support checkbox, generated the solution file and it listed that v141_xp toolset is forced, OK.
Went into VS2019 GUI, opened project properties and there was no sign of XP toolset settings, only the /Zc:threadSafeInit- option. It still listed the non-XP v142 toolset.
EDIT: When I pressed the "Generate" once again then it created the proper xp targeted solution

Last edited by pinterf; 23rd May 2020 at 05:36.
pinterf is offline   Reply With Quote
Old 23rd May 2020, 15:17   #193  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,766
This is a follow-up to this post:
https://forum.doom9.org/showthread.p...13#post1912913

Quote:
At this point I said: "It must be something forked from Avisynth Neo!"
so I installed Avisynth Neo x86 r2827 and it gave me ACCESS VIOLATION. The very same behavior of Avisynth 3.6.0!
"Aha!"
It seems that they share the same behavior...
and I do agree with FranceBB on his conclusion.

My issues occur under Win7-64 on a Core i5 CPU with 8GB of RAM.

I made some more tests with StaxRip v. 1.1.9.0 (the last stable 32-bit version from 2013). I have no idea how StaxRip interfaces with AviSynth. All I can say is that for all the very long time I am using StaxRip, it never gave me any issues with AVS versions starting from early 2.5x versions through 2.6x up to AVS+ 3.5.1.

The weird behavior with LAV filters was only revealed because I had enabled the tray icons for LAV. So it is very easy to see that multiple instances are still running.

For ffvideosource and LWLibavVideoSource it is hard to tell if they have the same problem. They do not have tray icons, and in Task Manager I did not find a way to tell if there are several processes for the same DLL active.

So all I can be sure of is that LAV filters are not released from memory after the script which invokes them has finished and is terminated by StaxRip. The only way to release these filter instances from memory is to terminate StaxRip.

This behavior has nothing to do with the AVS+ MT feature. It does not matter if the Prefetch call is present or commented out, the behavior is identical.

The next thing I tried was to use DirectShowSource instead of DSS2Mod. Not good at all. The LAV filters behavior was the same, but in addition StaxRip would crash after 30 to 50 seconds after opening the source. This is reproduceable each and every time regardless of the source file format.

Since I almost never use DirectShowSource for video I became curious. I went back to AVS+ 3.5.1 (identical scripts and settings) and loaded a source using DirectShowSource. LAV filters behaved normally, and there were no crashes. But I only got one third of the conversion speed compared to other source filters (including DSS2Mod). Again regardless if Prefetch was used or not. Very weird.

To be absolutely sure I removed AVS+ and went back to classic AVS 2.6.1 Alpha. And here DirectShowSource was only a tad slower than the other source filters (about 0.5 fps).

Does not make any sense to me...

In any case I feel that AVS+ 3.6 is not ready for prime time yet. Please implement a more thorough quality control before publishing "stable" builds which turn out to be not that stable at all.


Cheers
manolito
manolito is offline   Reply With Quote
Old 23rd May 2020, 16:41   #194  |  Link
stax76
Registered User
 
Join Date: Jun 2002
Posts: 6,291
@manolito

The StaxRip version you use is very old, it's using VFW, new versions use AviSynth and VapourSynth directly in portable mode, everything is included and works without installing or configuring anything, if AviSynth is installed then the installed version is used and the portable version cannot be used due to how AviSynth and tools are designed, StaxRip includes about ten tools that read avs and vpy. For VapourSynth both modes can be used, at least for what I could test (cannot test hw encoders). The beta from today uses AviSynth 3.6, works fine.

Last edited by stax76; 23rd May 2020 at 16:43.
stax76 is online now   Reply With Quote
Old 23rd May 2020, 16:42   #195  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,798
Quote:
Originally Posted by Boulder View Post
Here's an example of a script which starts pounding on the GPU at 100%. I've tried changing the prefetch value, but I've not found a good value which would put the CPU (12c/24t) to work at 90-100%. In Vapoursynth, a very similar script uses 95-100% of the CPU and is much faster. GPU usage stays below 10% almost all the time.

Code:
DGSource("potter_stone.dgi", ct=280, cb=280, cl=0, cr=0) # UHD source

c2 = convertbits(bits=16)
c2blur = c2.blur(0.2)
prefilt = convertbits(bits=10)

w = prefilt.width()
h = prefilt.height()
prefilt = prefilt.removegrain(12, 12).gaussresize(w, h, 0, 0, w+0.0001, h+0.0001, p=2).mergeluma(prefilt, 0.1)

sharp_luma = c2.sharpen(0.6)
sharp_chroma = c2.sharpen(0.2)
sharp = sharp_luma.mergechroma(sharp_chroma)

superanalyse = prefilt.msuper(pel=2, hpad=16, vpad=16, sharp=2, rfilter=4)
supermdg = sharp.msuper(pel=2, hpad=16, vpad=16, levels=1, sharp=2, rfilter=4)

fv1 = manalyse(superanalyse, isb=false, delta=1, blksize=64, overlap=32, search=5, searchparam=8, pelsearch=8, truemotion=false, dct=5, mt=false)
bv1 = manalyse(superanalyse, isb=false, delta=1, blksize=64, overlap=32, search=5, searchparam=8, pelsearch=8, truemotion=false, dct=5, mt=false)
fv1 = mrecalculate(superanalyse, fv1, thsad=100, blksize=32, overlap=16, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
bv1 = mrecalculate(superanalyse, bv1, thsad=100, blksize=32, overlap=16, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
fv1 = mrecalculate(superanalyse, fv1, thsad=100, blksize=16, overlap=8, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
bv1 = mrecalculate(superanalyse, bv1, thsad=100, blksize=16, overlap=8, search=5, searchparam=6, truemotion=false, dct=5, mt=false)

fv1scaled = fv1.mscalevect(bits=16)
bv1scaled = bv1.mscalevect(bits=16)

c2blur.mdegrain1(supermdg, bv1scaled, fv1scaled, thsad=200, thsadc=200, plane=4, limit=255, limitc=255, thscd1=200, thscd2=70)

Prefetch(24)
I'm still quite confused with these tests of mine.
Running the script with Prefetch(frames=1, threads=24) ends up in CPU usage which looks like it's using only one thread. AVSMeter tells me that the thread count is increased but CPU utilization is still around 4%. GPU usage stays low.

I thought that would emulate the old behaviour of SetMTMode(x, 24)?

I've tried various frames and threads combinations, but at best I've been able to get around 40-45% of CPU load. The source decoding becomes a bottleneck sooner or later as the amount of frames increases.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 23rd May 2020, 17:31   #196  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,766
Quote:
Originally Posted by stax76 View Post
@manolito

The StaxRip version you use is very old, it's using VFW, new versions use AviSynth and VapourSynth directly in portable mode, everything is included and works without installing or configuring anything, if AviSynth is installed then the installed version is used and the portable version cannot be used due to how AviSynth and tools are designed, StaxRip includes about ten tools that read avs and vpy. For VapourSynth both modes can be used, at least for what I could test (cannot test hw encoders). The beta from today uses AviSynth 3.6, works fine.
I see your point, but this will not work for me...

This old version 1.1.9.0 is very stable, it was at a time when you took a long break from StaxRip development. When you resumed the development, one of the first things you did was dropping XP support, and shortly after this you abandoned 32-bit completely.

I use StaxRip on at least 3 computers, and one of them is the ancient WinXP machine with a Coppermine CPU (no SSE2 support) and very low system RAM. I really do not want to maintain different StaxRip versions and different AVS plugins on these machines, they all use the "least common denominator" principle. Which means 32-bit and XP compatible.

There are also a couple of 32-bit only AVS plugins I want to keep on using, so I have no intention to ditch this old StaxRip version. Looking at your current StaxRip versions I can see that there are tons of new features which I do not care for (Hi Bit Depth, Hi Color, X265 support, VS support), but some things I do care for are missing (like XviD VFW support). And with all these new features also tons of new bugs were introduced.

So being a "Retro" person I will stick with this old StaxRip version, and if newer versions of AVS+ no longer support it then I will stop using these AVS+ versions. Newer is not always better...

Last edited by manolito; 23rd May 2020 at 17:43.
manolito is offline   Reply With Quote
Old 23rd May 2020, 17:43   #197  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,544
Quote:
Originally Posted by Boulder View Post
I'm still quite confused with these tests of mine.
Running the script with Prefetch(frames=1, threads=24) ends up in CPU usage which looks like it's using only one thread. AVSMeter tells me that the thread count is increased but CPU utilization is still around 4%. GPU usage stays low.

I thought that would emulate the old behaviour of SetMTMode(x, 24)?

I've tried various frames and threads combinations, but at best I've been able to get around 40-45% of CPU load. The source decoding becomes a bottleneck sooner or later as the amount of frames increases.
A minor note: vector scaling is no longer necessary with newer mvtools, MDegraining a 16 bit clip will accept vectors made from arbitrary bit depth source. This is why you can MDegrain even a 32 bit float clip.

I suppose, you get those numbers with older avisynth versions as well?
Last year (or before that) I investigated a similar source which behaved sub-optimally, to say at least. I could reach e.g. 60% CPU max. Could not solve it.

Vapoursynth has a rather different strategy on requesting frames. An Avisynth filter which requires e.g. 6 input clips (2-2 vector clips, super and the source clip itself) is requesting them in a serial ways inside a GetFrame. Caching helps a lot but not always. Contrary to this, Vapoursynth start requesting all 6 inputs _parallel_ and waits until they are all ready.

Maybe your case is a different one, which is only showing that the source filter (which is usually automatically set as MT_SERIALIZED mode) is getting more out of order (random) requests than it can cope with or cache.

Does your source filter have a debug or more verbose logging mode?
pinterf is offline   Reply With Quote
Old 23rd May 2020, 18:24   #198  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,798
Quote:
Originally Posted by pinterf View Post
I suppose, you get those numbers with older avisynth versions as well?
At least with v3.5.1 as I started my experiments with that version.

Quote:
Vapoursynth has a rather different strategy on requesting frames. An Avisynth filter which requires e.g. 6 input clips (2-2 vector clips, super and the source clip itself) is requesting them in a serial ways inside a GetFrame. Caching helps a lot but not always. Contrary to this, Vapoursynth start requesting all 6 inputs _parallel_ and waits until they are all ready.

Maybe your case is a different one, which is only showing that the source filter (which is usually automatically set as MT_SERIALIZED mode) is getting more out of order (random) requests than it can cope with or cache.
So the frames + threads parameter is not like "process m frames with n threads simultaneously"? Has the multithreading functionality changed a lot since SEt's Avisynth MT? Of course, it could be that it's much harder to utilize all the 24 threads the CPU has.

Quote:
Does your source filter have a debug or more verbose logging mode?
As far as I know DGSource doesn't have one, but I also tested LWLibavVideoSource with SW decoding and it doesn't resolve the issue.

Would you like me to test something specific? I also tried a BD source but it has the same problem, I cannot get CPU utilization past 40-45% or so.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 23rd May 2020, 19:41   #199  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,544
Quote:
Originally Posted by Boulder View Post
I'm still quite confused with these tests of mine.
Running the script with Prefetch(frames=1, threads=24) ends up in CPU usage which looks like it's using only one thread. AVSMeter tells me that the thread count is increased but CPU utilization is still around 4%. GPU usage stays low.

I thought that would emulate the old behaviour of SetMTMode(x, 24)?

I've tried various frames and threads combinations, but at best I've been able to get around 40-45% of CPU load. The source decoding becomes a bottleneck sooner or later as the amount of frames increases.
How much memory is required for all those 24 threads? Mvtools working area can be quite memory hungry for example, multiply it by 24 (filters are mostly MT_MULTI_INSTANCE mode) + UHD source. What is avsmeter telling? If it is near 4GB then use SetMemoryMax with e.g. 8000 or use a value which is probably above the memory need by a safe margin.

All you can do is experimenting and share your findings

1.) You can have now multiple Prefetchers (new in 3.6)
2.) At the moment, forget "frames" parameter
3.) Try another cache mode (new in 3.6) default is 0.
- SetCacheMode(0) or SetCacheMode(CACHE_FAST_START) start up time and size balanced mode
SetCacheMode(1) or SetCacheMode(CACHE_OPTIMAL_SIZE) slow start up but optimal speed and cache size
Latter can do wonders especially at really low memory environment
pinterf is offline   Reply With Quote
Old 23rd May 2020, 19:46   #200  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,544
BTW your script is using isb=false for both forward and backward vectors, which seems to be wrong.
pinterf is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.