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. |
1st April 2016, 22:17 | #1363 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Let's explore the options: 1. System32/SysWoW64 Every client can find and load avisynth.dll, be it 32 or 64 bit. 32 and 64 bit Avisynth can both be installed. 2. Any directory that is referenced in the "PATH" environment variable. The installer would need to parse the PATH environment and then ask the user where it should be placed. Also, this only works for either 32 or 64 bit. You decide which one is better. |
|
2nd April 2016, 00:20 | #1364 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
It doesn't need to be on the $PATH (actually, it shouldn't be on it). It's kinda late to do anything about all the ancient third-party software now, but the Right Thing is to just install into whatever folder the user chooses and use a registry key (different ones for 32- and 64-bit, obvs) to point to its location. VS does this. VfW programs can still load it as normal and everything that needs to interface with the DLL directly can find it via the registry key (or by letting the user point it out, if you want a portable version). Installing it globally was acceptable when Avisynth was designed (and you kinda had to do it, AFAIK?) but it's an all around awful idea. It's one of the many things Avs+ should've broken backwards compatibility with when they had the chance.
I haven't tried it, but the internet claims that if you have a 32-bit lib in one dir and the same lib except 64-bit in another dir, and both those dirs are on the $PATH, LoadLibrary is smart enough to figure out which one to grab for your process. Not that it's a thing you should do. Last edited by TheFluff; 2nd April 2016 at 00:34. |
2nd April 2016, 00:51 | #1365 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Therefore, the code of each of these clients (VDub, AVSP, x264, mpc(hc), ...) would have to be changed. And yes, in hindsight it may have been a good idea to use registry pointers. |
|
2nd April 2016, 06:59 | #1366 | Link |
Registered User
Join Date: Feb 2008
Posts: 59
|
Just trying to be slightly helpful and assumed the problem was windows deciding it knew best and thought it was blocking the DLL being put where he wanted it to be and the software was looking for it, as has happened to me when the OS thought everything was a suspicious file so either silently blocked it or poppingup nag requesters asking if its OK to run when installed software that calls other software
Such as AviSynth or other ones I use such as AVStoDVD that also had issues in the past. Not with the package but UAC blocking everything from running and permissions aggravation |
4th April 2016, 09:43 | #1369 | Link |
Registered User
Join Date: Mar 2012
Location: Saint-Petersburg
Posts: 239
|
That commit broke ffdshow.
It's impossible now for ffdshow to add a function into ScriptEnv. Code:
PluginManager::AddFunction() ... newFunc = AVSFunction(name, NULL, params, apply, user_data); assert(newFunc.IsScriptFunction()); ... AVSFunction::AVSFunction(const char* _name, const char* _plugin_basename, ...) ... if ((NULL != _name) && (NULL != _plugin_basename))
__________________
SVPflow motion interpolation |
4th April 2016, 13:41 | #1370 | Link | |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,297
|
Quote:
For having a proper support of XP, as it's explained here, you have to compile with the /Zc:threadSafeInit- option, otherwise it will not work. My advice would be, if you want to support XP, to make 2 builds. One generic with v140 toolset and no XP support, and another XP support specific, with v140_xp toolset and the /Zc:threadSafeInit- option. |
|
4th April 2016, 16:12 | #1371 | Link | |
Registered User
Join Date: Dec 2011
Posts: 354
|
Quote:
For your case, isn't it in syswow64 folder? Anyway If it's 64bit Windows, shouldn't you replace syswow64's dll? I don't know if it would help you since you guys are professional programmers. |
|
4th April 2016, 16:34 | #1372 | Link | |
Registered User
Join Date: May 2005
Posts: 1,462
|
Quote:
__________________
Gorgeous, delicious, deculture! |
|
4th April 2016, 16:48 | #1373 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
Tapatalkkal küldve az én GT-I9195I eszközömről |
|
4th April 2016, 16:54 | #1374 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
The issue that pinterf had was rectified, it had to do with inconsistent behaviour of file system redirection functions in the Windows API across various Windows versions. |
|
5th April 2016, 10:41 | #1375 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
(I realized that I have a Virtual XP in my Win7Prof). I will make a build later, since I made more debug mess in the code than you can imagine. Some progress: Last week I tried to narrow down the random-increasing memory consumption problem that I wrote earlier about. Frankly I was getting mad. The problem occured only when passing the 35800th frame and also from that time on in random waves. It's not easy to debug something that first appears after 15-20 minutes of running. This problem does not occur with colorbars, nor with a modded (non-static base frame) colorbars. Only with a DV-AVI. I already debugged the cache system (nice one :-)), put timestamps to each framebuffer registration to see which frames got stuck and did not get reused in the last 10 seconds. Yesterday I happily realized that it happens both with avisource or ffms2 so I could exclude them from the culprit list. After one week I found out that the behaviour is not time-dependent, today I made a brave Trim() from before the problematic frames and wonder! it started to eat memory from the same source frames. All I know that these frames have heavy camera shake. So it seems that one of the plugins in qtgmc(Fast) is leaking frames under these speficic circumstances. At least now I don't have to wait forever for the problem to occur. |
|
7th April 2016, 13:21 | #1376 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
|
Tested with AviSynth+ r1825 MT and r1828-pfmod (MSVC2015 Redist installed):
Code:
LoadPlugin("E:\Programme\AviSynth 2.5\plugins\LSMASHSource\LSMASHSource.dll") a=LwLibavAudioSource("truehd.mka").AssumeFPS(50,1) v=ColorBars(1280,720,"YV12").AssumeFPS(50,1).Trim(0,Round(a.AudioDuration*50.0)) AudioDub(v,a) Info() Histogram(mode="Audiolevels") Code:
AVSMeter 2.1.6 (x86) AviSynth+ 0.1 (r1828, MT-pfmod, i386) (0.1.0.0) System exception - Integer Divide by Zero (H:\Video\Test\truehd.avs, line 6) In original AviSynth up to v2.6.0 MT final, it loads the TrueHD track with 8 channels and displays audio levels overlayed. Last edited by LigH; 7th April 2016 at 13:24. |
7th April 2016, 13:45 | #1377 | Link |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
raffriff42 posted similar problems a while back also. Take a look at post #1251 through #1253.
@pinterf If is not a big deal, can you include PR #64 with your next build? Last edited by Reel.Deel; 29th May 2016 at 12:41. Reason: link |
7th April 2016, 18:13 | #1378 | Link |
typo lover
Join Date: May 2009
Posts: 595
|
__________________
my repositories Last edited by Chikuzen; 7th April 2016 at 18:35. |
8th April 2016, 00:19 | #1380 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Avisynth+ r1841-pfmod
http://www.mediafire.com/download/ea...r1841-pfmod.7z From readme: AvisynthPlus r1841-pfmod 2016.04.08 - TemporalSoften frame leak fix (short to write but it took me 30 hours ) - minor FrameRegistry2 tunings - PR #64 rgb24<->rgb32 ssse mod: https://github.com/AviSynth/AviSynthPlus/pull/64 - PR #65 Fix audio cache #65 (Chikuzen) - Colorbars new parameter: Boolean staticframes true (default): returns the precalculated static frame's pointer false: copies the precalculated frame into a new frame and returnes this new frame pointer - XP versions: v140_xp toolset with extra C++ commandline option /Zc:threadSafeInit- Very good memory consumption r1841: QTGMC(Fast) on x64 + Prefetch(8) + 720x576 DV-AVI Source = 350-400 MB r1828: QTGMC(Fast) on x64 + no MT + 720x576 DV-AVI Source = 200->1900 MB increasing Please test it, good night! |
Thread Tools | Search this Thread |
Display Modes | |
|
|