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. |
22nd May 2020, 18:34 | #182 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Thank you, unfortunately Error C2365 remains.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
22nd May 2020, 18:46 | #185 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
I think so, will try to workaround it tomorrow.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
22nd May 2020, 18:49 | #186 | Link | |
Registered User
Join Date: Jul 2012
Posts: 208
|
Quote:
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 |
|
22nd May 2020, 18:54 | #187 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,577
|
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)
__________________
@turment on Telegram Last edited by tormento; 22nd May 2020 at 18:57. |
22nd May 2020, 20:27 | #188 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
I'm not using these enums so just out comment them.
Maybe there is still time to rename these things?
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
23rd May 2020, 01:13 | #190 | Link | ||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
Quote:
Quote:
I even tried with Code:
SetMaxCPU("none") ColorBars(848, 480) 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. |
||
23rd May 2020, 01:59 | #191 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Test this one (32-bit only):
http://www.mediafire.com/file/we5m23...nosimd.7z/file |
23rd May 2020, 05:21 | #192 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
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. |
23rd May 2020, 15:17 | #193 | Link | |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
This is a follow-up to this post:
https://forum.doom9.org/showthread.p...13#post1912913 Quote:
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 |
|
23rd May 2020, 16:41 | #194 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
@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.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists Last edited by stax76; 23rd May 2020 at 16:43. |
23rd May 2020, 16:42 | #195 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,731
|
Quote:
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... |
|
23rd May 2020, 17:31 | #196 | Link | |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Quote:
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. |
|
23rd May 2020, 17:43 | #197 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
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? |
|
23rd May 2020, 18:24 | #198 | Link | |||
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,731
|
Quote:
Quote:
Quote:
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... |
|||
23rd May 2020, 19:41 | #199 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
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 |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|